Support type-relative assoc item paths in generic param defaults & const param types

[fmease]

Background info: For resolving type-relative associated item paths, we only support a tiny set of self types (cc #22519). If it's a non-Self type parameter we'll look through the "type param bounds" of the overarching item.

However, in the case of generic parameter defaults and const parameter types this overarching "item" was set to the generic parameter. This meant that in these places we didn't look at the list of bounds of the overarching item when trying to resolve such type-relative associated item paths but at the one of the generic parameter which is always empty¹ and thus failed unconditionally.

Fixes #87682.

For the types FCP: This PR makes us accept the following code (stably):

trait Trait { type Type; }

struct Owner<T: Trait, U = T::Type>(T, U);
//                         ~~~~~~~ now successfully resolves to <T as Trait>::Type

As alluded to, this PR also affects the resolution in const param defaults+types (intentionally, of course). However, I don't think this can be observed without the use of unstable features (like min_generic_const_args and generic_const_parameter_types). Nonetheless if you're interested in that, too, please check out the added UI tests.

To the best of my knowledge this change doesn't make us reject more code (via new ambiguities or query cycles for example).

_{(No LLM was or will be used by me during the entire creation process of this PR)}

Footnotes

1. Generic params obviously never have generic params or bounds (à la (pseudo) struct S<T<X: Trait> = X::Type>) in the current version of Rust. ↩

[fmease]

r? types

[fmease]

@rfcbot merge types

[rust-rfcbot]

@fmease has proposed to merge this. The next step is review by the rest of the tagged team members:

• @BoxyUwU
• @jackh726
• @lcnr
• @oli-obk
• @spastorino

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[fmease]

Not sure if this needs an FCP but it felt "significant" enough. Since there's no breakage AFAIK & it's a bit niche, this might also be considered a trivial bugfix in which case I'm sorry for the team ping ^^'

[lcnr]

this needs a comment :>

also, does it make sense to exhaustively match on Node here/move this into a subfn?

View changes since the review

[fmease]

Are you referring to the following?

    let def_id = match hir_node {
        Node::GenericParam(_) => tcx.local_parent(def_id),
        _ => def_id,
    };

I'd really rather not (not even in a subfn) since Node has 37 variants of which most aren't even allowed and more importantly due to the fact that immediately below the construction of the ItemCtxt, we matching on Node again which is actually the "main match" of the type_of function where we list out 15 variants explicitly.

Having two separate giant exhaustive matches would just obscure the intention of the code.

I'd rather move the construction of the ItemCtxt into each individual branch of the "main match" which would sadly also render the code needlessly verbose and hard to follow since in all cases except for, well, Node::GenericParam, the construction is identical. Okay, I could also make the icx binding mut and just throw away the ItemCtxt in the GenericParam case and construct it anew but now with the parent DefId.

I do love exhaustive matches, I really do, but I think a comment on the let def_id = match … { … }; would be entirely sufficient in this specific case.

[fmease]

Alternatively, alternatively, we could do what we do for Node::Field and keep the type_of impl alone but set the ty::Generics.parent to Some(item_def_id) in generics_of (currently: None).

This would also make all 3 tests compile.

Edit: Let's do that instead (c16c10d).
Edit 2: Nvm, let's not; it leads to query cycles in ~100 GCE UI tests ^^
Edit 3: Maybe we could switch to that impl once GCE has been thrown out? I haven't yet thought if it's a 100% correct

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.