rustc fails to resolve an associated type when using Self: Trait<A> in a method of a trait

[hadronized]

Somewhat minimal reproducible code:

pub trait Foo<L> {
    type Repr;

    fn foo(repr: &Self::Repr);
}

pub trait Bar {
    fn bar<L>(repr: &Self::Repr)
    where
        Self: Foo<L>;
}

// now let’s implement Bar for a type
#[derive(Debug)]
pub struct Hello {
    pub handle: u32,
}

impl<L> Foo<L> for u32 {
    type Repr = Hello;

    fn foo(repr: &Self::Repr) {
        println!("{:?}", repr);
    }
}

// the weird things start here; notice how we need <Self as Base<L>> here
impl Bar for u32 {
    fn bar<L>(repr: &<Self as Foo<L>>::Repr)
    where
        Self: Foo<L>,
    {
        println!(
            "{}",
            repr.handle // <- opaque type here
            //unsafe { std::mem::transmute::<_, &Hello>(repr) }.handle // <- current workaround :()
        );
    }
}

fn main() {
    let h = Hello { handle: 3 };
    u32::bar::<()>(&h);
}

I expected to see this happen: code should compile just fine.

Instead, this happened: result from rustc:

error[E0609]: no field `handle` on type `&<u32 as Foo<L>>::Repr`
  --> src/main.rs:52:18
   |
52 |             repr.handle // <- opaque type here
   |                  ^^^^^^

error: aborting due to previous error

Meta

Bug present in both stable and nightly (I haven’t tested beta but I guess it’s there too).

rustc --version --verbose:

rustc 1.41.0 (5e1a79984 2020-01-27)
binary: rustc
commit-hash: 5e1a799842ba6ed4a57e91f7ab9435947482f7d8
commit-date: 2020-01-27
host: x86_64-unknown-linux-gnu
release: 1.41.0
LLVM version: 9.0

Backtrace

N/A

[hadronized]

Just starting the discussion: people on Reddit told me that Self: _ is an anti-pattern (which I disagree with, it’s a very useful feature, and it works with Self: Trait if Trait has no type variable).

If you think a bit about it, Self: Trait<A> on a method should be fine as the method’s impl is available only if Self implements Trait<A>. Only that method has access to Trait<A>’s items, and the rest of the trait is fine.

Also, I think I’ve found another workaround: split the trait into two smaller traits and move the type variable to one of the trait. That should work but it’s annoying.

[Enselic]

The compiler is probably confused by the unused generic param T. If <T> (and the one instance of ::<()>) is removed from the code everywhere, it compiles.