Associated types appear to cover or hide generic parameters in orphan rules checking

[steffahn]

Here’s a soundness issue in the orphan rules checker. @rustbot label I-unsound, A-traits, A-associated-items, T-compiler.

One crate foo defines

pub trait Trait<Arg> {}

If a downstream crate uses foo and tries to implement

use foo::Trait;

pub struct Local<T>(T);

impl<T> Trait<Local<T>> for T {}

it fails as expected

error[E0210]: type parameter `T` must be covered by another type when it appears before the first local type (`Local<T>`)
 --> dep1/src/lib.rs:5:6
  |
5 | impl<T> Trait<Local<T>> for T {}
  |      ^ type parameter `T` must be covered by another type when it appears before the first local type (`Local<T>`)
  |
  = note: implementing a foreign trait is only possible if at least one of the types for which it is implemented is local, and no uncovered type parameters appear before that first local type
  = note: in this case, 'before' refers to the following order: `impl<..> ForeignTrait<T1, ..., Tn> for T0`, where `T0` is the first and `Tn` is the last

and rightfully so, since other crates depending on foo might define an impl<T> Trait<T> for OtherLocal {} that overlaps.

But we can circumvent this error using a trait with an associated type, violating the orphan rules!

use foo::Trait;

pub struct Local<T>(T);

impl<T> Trait<Local<T>> for <T as WithAssoc>::Assoc {}

// implementing `<T as WithAssoc>::Assoc` to be `T`:

pub trait WithAssoc {
    type Assoc;
}

impl<T> WithAssoc for T {
    type Assoc = T;
}

(compiles fine)

I have only managed to turn this into an ICE during code generation so far, not UB at run-time, but I would be surprised if there wasn’t a way to actually exploit this bug, hence the label. I’ll look back into this in the next few days and either post a soundness exploit, or at least the way to achieve ICE.

[steffahn]

Nevermind, it’s a duplicate of #99554