Go to definition doesn't work for trait implementations for structs inside function bodies

[HKalbasi]

trait T {
    type Ty;
    fn foo() -> Self::Ty;
}

fn f() {
    struct X {}
    impl T for X {
        type Ty = i32;
        fn foo() -> i32 {
            5
        }
    }
    let t = X::foo();
}

In this example r-a sees method, and can infer that the type of t is i32, but go to definition on foo will go to the trait function, not the impl one.

[Veykril]

In general, IDE features like these interacting with impls should be aware of block impls for the cursor position.

[HKalbasi]

Why cursor position? I noticed this when trying to mir interpret some function in standard library which used this pattern, I guess cursor position wouldn't work for it. Isn't is possible to consider the block impls of the self type in lookup_impl_method?

[Veykril]

We cannot consider all block implementations, for that we would need to look into all bodies which goes against the lazy analysis strategy we employ in r-a.

[Veykril]

(Note cursor position in this case would be identifier we are invoking this go to on, so take cursor position as "relevant context position for the current task")

[Veykril]

Oh I see, sorry. I assumed the go to def fuctionality was faulty. But this is the infernece results not recording properly. Point still stands, for resolving thefoo in X::foo we should consider impls in the surrounding block and all ancestors (which I relaly thought we already do?)

[HKalbasi]

We cannot consider all block implementations, for that we would need to look into all bodies which goes against the lazy analysis strategy we employ in r-a.

This case is allowed in rust-lang/rfcs#3373 so we should support it, but I think it is possible to do it without breaking laziness.

for resolving thefoo in X::foo we should consider impls in the surrounding block and all ancestors (which I relaly thought we already do?)

I guess we do it in method resolution, but not in the lookup_impl_method function.

[Veykril]

Indeed, it looks like lookup_impl_method is losing the local context, that is the block its used in, so we need to thread that through somehow. The callers also don't respect block impls for the current block for the passed trait environment.