This is for future-proofing / an extension of my efforts to make object lifetime defaulting more predictable & consistent across generic containers (see also #129543).

Examples that currently compile but ought not to:

#![feature(inherent_associated_types)] struct Self0; impl Self0 { type Project<'a, T: 'a + ?Sized> = (); } type Demo0<'r> = Self0::Project<'r, dyn Trait>; // ^^^^^^^^^ ought to be rejected struct Self1<'a>(&'a ()); impl<'a> Self1<'a> { type Project<T: 'a + ?Sized> = (); } type Demo1<'r> = Self1<'r>::Project<dyn Trait>; // ^^^^^^^^^ ought to be rejected trait Trait {}

Note that this shouldn't/doesn't affect cases where the trait object types has own bounds that can be used as they take precedence (which The Reference gets wrong, cc rust-lang/reference#1407). Example of something that isn't affected:

#![feature(inherent_associated_types)] trait Trait: 'static {} // ^^^^^^^ (!) struct Zelf; impl Zelf { type Project<'a, T: 'a + ?Sized> = (); } type Demo0<'r> = Zelf::Project<'r, dyn Trait>; // ^^^^^^^^^ OK! // This elaborates to `dyn Trait + 'static` // due to the bound on `Trait` which takes // precedence over "`named_bound_var`".

We need to set the ambient object lifetime default for inherent projections to None in resolve_bound_vars, this way it'll be rejected later in ItemCtxts during HIR ty lowering.

"Problem" (the crux of the matter, actually): We don't have the resolution of TypeRelative paths in RBV, so arguably we should just do that for all unknown¹ TypeRelative paths. I tried that already in #129543 and crater came back clean! I might just fix this issue in #129543 come to think about it.