Opaque types' generic params do not imply anything about their hidden type's lifetimes

[oli-obk]

fixes #97104

cc @aliemjay

[rust-highfive]

r? @cjgillot

(rust-highfive has picked a reviewer for you, use r? to override)

[aliemjay]

Looks good. Thanks!

I'm thinking if we should consider forcing the hidden type to constrain all generic params of the type alias in TAIT. If so, we won't have such weird differences between opaque types Adts. I'll discuss it further in a zulip stream https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/generic.20TAIT.20problems/near/286519266

[cjgillot]

r? rust-lang/types

[lcnr]

don't fully understand whether this is the correct fix, not sure whether #97104 has a meaningful relation to impl trait 😅 the ub here doesn't rely on impl trait at all.

trait Foo<ARG: 'static>: 'static {
    type Assoc: AsRef<str>;
}

fn hr_shit<T: ?Sized, ARG>(x: T::Assoc) -> Box<dyn AsRef<str> + 'static>
where
    T: Foo<ARG>
{
    Box::new(x)
}

fn extend_lt<'a>(x: &'a str) -> Box<dyn AsRef<str> + 'static> {
    type DynTrait = dyn for<'a> Foo<&'a str, Assoc = &'a str>;
    hr_shit::<DynTrait, _>(x)
} 

fn main() {
    let extended = extend_lt(&String::from("hello"));
    println!("{}", extended.as_ref().as_ref());
}

I think we already have an issue for this?

edit: I think that's #44454

[bors]

☔ The latest upstream changes (presumably #98206) made this pull request unmergeable. Please resolve the merge conflicts.

[aliemjay]

@lcnr I believe the your reduced example is a separate problem, completely orthogonal to the one in hand.

The type dyn for<'a> Callable<Opaque<&'a ()>, Output = &'a str> must to be rejected because the lifetime 'a doesn't necessarily constrain the TAIT and thus can't appear in the associated type as dictated by RFC 1214, it's exactly the same reason we reject projection types in dyn for<'a> Callable<<&'a str as IntoIterator>::Item, Output = &'a str>.

Meanwhile, the type from your example dyn for<'a> Foo<&'a str, Assoc = &'a str>, I believe, is a valid one and should not be rejected per-se, because it requires checking the WF of the TraitRef before each instantiation of 'a. If anything, we should error in hr_shit::<DynTrait, _>(x)

[lcnr]

seems good, so after my nits are dealt with, r=me

[lcnr]

why is the note "lifetimes appearing in an associated type are not considered constrained" not emitted here?

[oli-obk]

We're not checking for higher kinded lifetimes in the diagnostic, we're just checking for names. It would be a larger refactoring to handle the difference between lifetimes on the type alias and lifetimes in a binder.

[oli-obk]

@bors r=lcnr

[bors]

📌 Commit 64d11fc has been approved by lcnr

It is now in the queue for this repository.