Trait methods can't be found by method resolution if the `self` type involves projections

[steffahn]

I tried this code:

pub type Id<T> = <T as IdTrait>::T;

pub trait IdTrait {
    type T: ?Sized;
}

impl<T: ?Sized> IdTrait for T {
    type T = T;
}

#[derive(Copy, Clone)]
struct Foo;
impl Foo {
    fn method(self: Id<Self>) {
        println!("hi!");
    }
}

trait FooTrait {
    fn method2(self: Id<Self>);
}
impl FooTrait for Foo {
    fn method2(self) { // or `: Id<Self>`, makes no difference here
        println!("hi!");
    }
}

pub fn main() {
    let foo = Foo;
    foo.method(); // works
    foo.method2(); // doesn't work
    Foo::method2(foo); // works
}

(playground)

I expected to see this happen: Code compiles successfully

Instead, this happened:

error[E0599]: no method named `method2` found for struct `Foo` in the current scope
  --> <source>:31:9
   |
12 | struct Foo;
   | ---------- method `method2` not found for this struct
...
20 |     fn method2(self: Id<Self>);
   |                      -------- the method might not be found because of this arbitrary self type
...
31 |     foo.method2(); // doesn't work
   |         ^^^^^^^
   |
help: there is a method `method` with a similar name
   |
31 |     foo.method(); // doesn't work
   |         ~~~~~~

error: aborting due to 1 previous error

For more information about this error, try `rustc --explain E0599`.
Compiler returned: 1

This is technically an old regression in 1.22, the code compiled fine up to Rust 1.21.

[steffahn]

Of course, fixing this is also technically breaking (though unlikely problematic in practice, because who writes signatures like this?) because it not only causes compilation errors but also allows for fallbacks further down the line in method resolution candidates

pub type Id<T> = <T as IdTrait>::T;

pub trait IdTrait {
    type T: ?Sized;
}

impl<T: ?Sized> IdTrait for T {
    type T = T;
}

#[derive(Copy, Clone)]
struct Foo;
impl Foo {
    fn method_a(&self) {
        println!("assoc method_a!");
    }
    fn method_b(&self) {
        println!("assoc method_b!");
    }
}

trait FooTrait {
    fn method_a(self);
    fn method_b(self: Id<Self>);
}
impl FooTrait for Foo {
    fn method_a(self) {
        println!("trait method_a!");
    }
    fn method_b(self) {
        println!("trait method_b!");
    }
}

pub fn main() {
    let foo = Foo;
    foo.method_a(); // trait method_a!
    foo.method_b(); // assoc method_b!

}

(playground)

trait method_a!
assoc method_b!

[steffahn]

@rustbot label +T-compiler, A-traits, A-typesystem, A-resolve, -needs-triage

[compiler-errors]

For anyone investigating this from the compiler side (i.e. I'm not gonna translate to normal people speech), this is because we're not normalizing the xform_self_ty in method probing for trait candidates 🤦

[dingxiangfei2009]

I gave it a try in normalizing xform_self_ty in fn consider_probe and rightfully I got back an obligation.

Obligation(predicate=Binder { value: ProjectionPredicate(AliasTy { args: [?2t], def_id: DefId(0:6 ~ once[0394]::IdTrait::T) }, Term::Ty(?3t)), bound_vars: [] }, depth=1)

Alternatively, with -Znext-solver, I got this obligation.

Obligation(predicate=Binder { value: AliasRelate(Term::Ty(Foo), Subtype, Term::Ty(Alias(Projection, AliasTy { args: [?2t], def_id: DefId(0:6 ~ once[0394]::IdTrait::T) }))), bound_vars: [] }, depth=0)

Both look very right to me. The hard part is to solve for the inference variable ?2t here, which is really just the Self type of the trait ref under probing. I am not sure how to unify ?2t with the proposed self_ty at the moment.

So @compiler-errors, would you mind dropping a hint at how this could be done? Thank you so much!

[dingxiangfei2009]

Actually I have thought about it a bit more. I am not sure if unifying Self with self_ty makes sense in most cases. We could apply heuristic, like adding or dropping reference, but it won't work in general. 🤔

[dingxiangfei2009]

I think we can perform the normalization, but I don't think we can fulfill <?'2 as IdTrait>::T == Foo by directly inferring ?'2 is Foo. It may have to consider specialization cases and I might need some mentoring, or leave it as is for now because there might be unknown consequences.

// We might override the blanket impl IdTrait if we have specialization in associated type
impl IdTrait for Baz {
    type T = Foo;
}
// So then we need to use impl FooTrait for Baz. Should specialization allow this probe result, or no?

cc @compiler-errors I have a tiny patch ready to just apply the normalization, but at this point I can't "solve" this issue entirely.