GAT lifetime mismatch with type parametrised over dyn trait object with restricted lifetime

[dhardy]

#![feature(generic_associated_types)]

pub trait A {}
impl A for &dyn A {}
impl A for Box<dyn A> {}

pub struct P<'a, T: ?Sized>(&'a T);
impl<'a, T: ?Sized> A for P<'a, T> {}

pub struct Q<T: ?Sized> {
    _pd: std::marker::PhantomData<T>,
}
impl A for Q<dyn A> {}

pub trait B {
    type T<'a>: A;
}

impl B for () {
    // this is ok:
    // type T<'a> = &'a dyn A;
    
    // so is this:
    // type T<'a> = P<'a, dyn A + 'a>;
    
    // this is not:
    type T<'a> = Box<dyn A + 'a>;
    
    // nor is this:
    // type T<'a> = Q<dyn A + 'a>;
}

// Note that this is also fine:
fn _f<'a>(_x: &'a ()) -> Box<dyn A + 'a> { todo!() }
// and so is this:
fn _g<'a>(_x: &'a ()) -> Q<dyn A + 'a> { todo!() }

Error:

error[E0308]: mismatched types
  --> src/lib.rs:27:5
   |
27 |     type T<'a> = Box<dyn A + 'a>;
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ lifetime mismatch
   |
   = note: expected trait `A`
              found trait `A`
note: the lifetime `'a` as defined on the associated item at 27:12...
  --> src/lib.rs:27:12
   |
27 |     type T<'a> = Box<dyn A + 'a>;
   |            ^^
   = note: ...does not necessarily outlive the static lifetime

Note also that a few months back, the nightly available did accept this type of code.

[b-naber]

I don't think this is a bug. What happens here is that the implementation of A for Box<dyn A> is used as a candidate for the trait object A in the Type alias type T<'a> = Box<dyn A + 'a>. Since impl A for Box<dyn A> resolves to impl A for Box<dyn A + 'static> the lifetime 'a in the TyAlias is equalized to 'static. If you parameterize over any lifetime (impl<'a> A for Box<dyn A + 'a>) then your first example compiles.

[dhardy]

The second example can be "fixed" in the same way: impl<'a> A for Q<dyn A + 'a> {}

But, by that logic, _f and _g should also fail to compile, so I'm not convinced.

[b-naber]

In the functions the lifetime in the trait object is resolved to the lifetime supplied by the function _f<'a>.

What behaviour would you expect here, i.e. what lifetime would you expect 'a to be in the associated type?

I'd agree that it's inconsistent though that the lifetimes in type T<'a> = &'a dyn A and type T<'a> = P<'a, dyn A + 'a> are not resolved to 'static.

Edit: No actually I think type T<'a> = &'a dyn A and type T<'a> = P<'a, dyn A + 'a> are correct, in impl A for &dyn A the lifetime is elided, so not necessarily resolved to static and in impl<'a, T: ?Sized> A for P<'a, T> {} you use a lifetime parameter so that 'a in P<'a, dyn A + 'a> is also an arbitrary lifetime and not 'static. Still don't see that this is a bug.

[dhardy]

Well then I have two questions:

1. Why is Box<dyn A> resolved to 'static instead of an elided lifetime? I suppose since it is simpler and usually works.
2. Why does fn _f ... work — simply because there is no :A bound as in the trait? (Indeed, removing this bound from the assoc type fixes both failures.)

Then you may be right and this is no more than unclear documentation error message.

[b-naber]

I'm not completely sure, but to me it seems most plausible that in impl A for Box<dyn A> the lifetimes for the trait object A are taken from the surrounding impl, which resolves to 'static, since its declared in global scope and no lifetime parameter is supplied.

I think _f works for the reason I explained in the previous comment. I don't believe it has anything to do with the trait bound. The reason that impl B works without the bound on the associated type could be that the compiler doesn't have to use impl A for Box<dyn A> as a candidate trait implementation and therefore possibly chooses impl A for &dyn A as the candidate for the trait object A in type T<'a> = Box<dyn A>, and since that implementation has an elided lifetime we don't get the 'static lifetime error.

But I could be wrong since I'm not that familiar with the trait system, the right person to answer this would be @matthewjasper

[dhardy]

In the functions the lifetime in the trait object is resolved to the lifetime supplied by the function _f<'a>.

This argument doesn't make sense to me since the associated types have a lifetime supplied in the same way — the key difference, assuming that associated types are resolved in the same way as other types, is the lack of a bound. Note that this also works (no bound, not associated):

type X<'a> = Box<dyn A + 'a>;

[dhardy]

BTW I wrote these test cases which may/may not be of use here.

issue-78113.zip