Tweak where_clauses_object_safety lint to allow auto traits

[alecmocatta]

This tweaks the lint of #51443 to not fire when all the bounds are auto traits.

Auto traits do not impact vtables, and as discussed in that issue, the lint firing in cases like this is a false positive.

This example currently errors, but succeeds with this commit:

#[deny(where_clauses_object_safety)]

trait Y {
    fn foo(&self) where Self: Send {}
}
impl Y for () {}

fn main() {
    <dyn Y + Send as Y>::foo(&());
}

(Playground)

Errors:

   Compiling playground v0.0.1 (/playground)
warning: the trait `Y` cannot be made into an object
 --> src/main.rs:4:5
  |
4 |     fn foo(&self) where Self: Send {}
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(where_clauses_object_safety)]` on by default
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #51443 <https://github.com/rust-lang/rust/issues/51443>
  = note: method `foo` references the `Self` type in where clauses

    Finished dev [unoptimized + debuginfo] target(s) in 1.06s
     Running `target/debug/playground`

[rust-highfive]

r? @matthewjasper

(rust_highfive has picked a reviewer for you, use r? to override)

[Centril]

r? @nikomatsakis

---

While it is true that:

Auto traits do not impact vtables, [...]

it also seems to me that this is complicating the type system by introducing more places in the typing rules where distinctions are drawn between regular traits and auto traits. Some language team discussion might be in order.

[nikomatsakis]

Hmm. I spent a bit of time reading into the history of this lint. It feels very related to the other dyn-trait-related soundness hole we are working on.

I agree with @Centril that I'd prefer not to "special case" auto traits here -- in fact, I'm not sure I understand yet why they are safe, even, because I've not brought this back into cache sufficiently.

[matthewjasper]

Yes, it's really unsound. We can't remove the check there, since it may not be possible to codegen the method if it uses a trait implementation that doesn't exist.

[alecmocatta]

Okay I see what I was missing. Thanks for clearing that up!

Given my PR would allow the below it shouldn't be merged in it's current form; I'll have a closer look over the next week.

#![feature(optin_builtin_traits)]

trait Trait {
    fn foo(&self) where Self: Auto {}
}
impl Trait for () {}

auto trait Auto {}
trait Nobody {}
impl<T> Auto for T where T: Nobody {}
impl Auto for dyn Trait {}

fn main() {
    <dyn Trait>::foo(&())
}

Playground

[alecmocatta]

Rather than "forbid traits" or "forbid non-auto traits", it seems this lint should be "forbid traits that are implemented on dyn Trait but not for all T where T: Trait". I don't have the bandwidth to to familiarize myself sufficient to know the best way to go about doing this; but if someone's able to mentor/point in the right direction I can give it a go.

[JohnCSimon]

Ping from triage:
Can anyone help @alecmocatta With this?
@nikomatsakis @matthewjasper @Centril
Thanks.