Improve RTN support (resolution + analysis; jump to definition, etc)

[compiler-errors]

rust-analyzer version: rust-analyzer version: 0.3.2330-standalone (02862f5 2025-03-03)

rustc version: rustc 1.87.0-nightly (f9e0239a7 2025-03-04)

editor or extension: VSCode

relevant settings: N/A

repository link (if public, optional): N/A

code snippet to reproduce:

#![feature(return_type_notation)]

trait Foo {
    async fn method();
}

async fn foo<T: Foo>() where T::method(..): Send {}

Hiya. r-a still lacks RTN support in resolution and presumably elsewhere in the type system, so I'm opening a tracking issue for that :) I'd be happy to mentor any technical work here to improve RTN (especially to help understand how RTN works in rustc), since I'm looking to stabilize RTN soon.

[ChayimFriedman2]

How does RTN work wrt. the trait env? I mean, it needs to be part of the trait env because it can introduce bounds, but we also need the trait env to lower it (to iterate over methods) - so how do we build it? In two steps?

[compiler-errors]

@ChayimFriedman2: RTN is no different than associated types wrt lowering and resolution, except for the namespace that it resolves its associated item in, and some caveats about introducing new higher ranked lifetimes for all the generics in scope. It should use the same strategy for resolving where T::Assoc: Bound.

In rustc, we don't need to lower an RTN type to iterate over methods, since we just need the list of methods and to inspect their HIR (that is, not their rustc_middle::ty type-system representation) to gather the information we need.

[ChayimFriedman2]

Does that means we need another kind of Chalk bound, and a way for Chalk to ask us to normalize it?

[compiler-errors]

No. Let me explain:

trait Foo {
    fn method() -> impl Future<Output = ()>;
}

fn usage<T: Foo>() where T::method(..): Send {}

In usage, we resolve T::method in the same fashion as an associated type, but looking for an associated function instead of an associated type. If we resolve it successfully, we query for the signature of the function, and try to grab the outermost RPITIT (we don't support anything other than -> impl Trait, e.g. we disallow -> Box<impl Trait> or -> (impl Trait,)) and then lower an associated type for that RPITIT.

Thus it ends up lowering like: fn usage<T: Foo>() where T::{method's-RPITIT}<>: Send. This shouldn't involve the type system or trait solver at all.

[ChayimFriedman2]

@compiler-errors How does rustc infers the value of the implicit associated type of RTN for impls? E.g.:

trait Trait {
    fn foo() -> Option<impl Sized>;
}

impl Trait for () {
    fn foo() -> Option<i32> { 0 }
}

The implicit associated type should be i32.

(It seems rust-analyzer does not yet lower RPITIT to associated types, so I'll have to do that first).

[compiler-errors]

https://rustc-dev-guide.rust-lang.org/return-position-impl-trait-in-trait.html#the-rpitit-inference-algorithm has some info for the inference algorithm we use for RPITITs