Object lifetime defaults of GATs are not respected

[fmease]

To infer the default trait object lifetime of a trait object type, we first look at the bounds on the relevant type parameter of the containing generic type. According to my interpretation of the Reference, RFC 599 and RFC 1156, any kind of generic type can be an elegible container type, not just ADTs. However, if the containing generic type is a GAT, the compiler doesn't properly take into consideration the bounds on its type parameters. The RFCs obviously predate GATs.

For example, I expected the following code to compile since dyn Inner in g's signature should be equivalent to dyn Inner + 'r given that 'r is the object lifetime default due to the bound T: 'a at least according to my reading of the Reference and according to #[rustc_object_lifetime_default] but it fails because the default is actually inferred to be 'static leading me to assume that rustc completely ignores the GAT param bounds.

trait Outer {
    type Ty<'a, T: ?Sized + 'a>;
}
impl Outer for () {
    type Ty<'a, T: ?Sized + 'a> = &'a T;
}
trait Inner {}

fn f<'r>(x: <() as Outer>::Ty<'r, dyn Inner + 'r>) { g(x) } //~ ERROR lifetime may not live long enough
fn g<'r>(_: <() as Outer>::Ty<'r, dyn Inner>) {}

error: lifetime may not live long enough
  --> src/lib.rs:10:56
   |
10 | fn f<'r>(x: <() as Outer>::Ty<'r, dyn Inner + 'r>) { g(x) }
   |      -- lifetime `'r` defined here                     ^ cast requires that `'r` must outlive `'static`

As attested by #[rustc_object_lifetime_default], we seem to (be able to) compute the object lifetime defaults for GATs (but we don't use them during resolution):

error: 'a
 --> src/lib.rs:5:17
  |
5 |     type Ty<'a, T: ?Sized + 'a>;
  |                 ^

---

Is this an oversight in the current implementation or does this work as intended?
Note that it would be a breaking change to fix this, I'm almost certain.

@rustbot label C-bug T-compiler A-lifetimes A-trait-objects A-associated-items F-generic_associated_types

[fmease]

Nominating this for lang team discussion since I really don't know if this works as intended or not.

Feel free to remove the nomination if you don't think it's important enough for a team discussion.
I can nominate it for a types team discussion instead if you think that's more appropriate :)

[fmease]

Possibly relevant: #91302

[nikomatsakis]

Hi @fmease !

We discussed this in our @rust-lang/lang triage meeting today. We felt the behavior is a bug and inconsistent. I'm nominating this issue for @rust-lang/types to discuss further and possibly fix.

@rustbot labels +I-types-nominated -I-lang-nominated

In particular, we felt that this example should behave the same as your motivating example:

trait Ref<'a, T: 'a + ?Sized> {
    type Ty;
}
trait Inner {}

fn f<'r, T>(x: <T as Ref<'r, dyn Inner + 'r>>::Ty) { g(x) }
fn g<'r, T>(x: <T as Ref<'r, dyn Inner>>::Ty) { g(x) } 

However, the above example gives an error, as does dyn Trait, but the GAT case seems to infer a bound of 'static. This seems like a bug. If any bound is inferred, in my opinion, it ought to be 'r.

We felt that it was ok to give a hard error since that is forwards compatible and consistent with how we currently behave for other parameters appearing in associated type references, but of course that is technically a breaking change, although the impact seems likely to be small.

@rust-lang/types, this kind of detail also feels like it's in your purview, how do you think we ought to proceed?

[lcnr]

discussed this in the @rust-lang/types meeting: zulip

our takeaways are as follows:

• object lifetime defaults for projections are currently unspecified and something we should clean up
• we should move towards handling projection arguments (and self type) by only looking at bounds on the trait declaration
• write PR, run crater, add tests, start a types fcp changing this behavior

This is theoretically breaking as &'a <dyn Trait as Foo>::Assoc currently infers to &'a <dyn Trait + 'a as Foo>::Assoc but would change to 'static with the proposed change. Hopefully not too many - or well, no - crates depend on the current behavior