`impl Trait` and bounds on associated types can produce values that mention invalid lifetimes

[theemathas]

View all comments

This was discovered by @danielhenrymantilla.

It seems that a value of type impl Trait<'a> + 'static can be used even if the lifetime 'a has already expired. This then can be used to produce a value of type &'a Thing, where 'a has already expired. For example:

fn foo<'r>(r: &'r str) -> impl 'static + Into<&'r str> {
    struct Wrapper(::core::ptr::NonNull<str>);
    
    impl<'r> Into<&'r str> for Wrapper {
        fn into(self) -> &'r str {
            unsafe {
                // Safety: `Wrapper` becomes an `impl use<'r> + Into<&'r str>`
                // so it cannot yield something with anything else than this `'r`
                // lifetime (or a covariant shrinkage thereof).
                self.0.as_ref()
            }
        }
    }
    
    Wrapper(r.into())
}

fn main() {
    let a = foo(&String::from("huh"));
    let _unrelated = String::from("UB!");
    dbg!(a.into());
}

The above code has one unsafe block, and causes use-after-free. It's unclear if this use of unsafe is correct or not, so I don't know if this is a soundness issue in rust's borrow checker.

As far as I can tell, this cannot cause UB without unsafe code. But still, it seems worrying.

Meta

Reproducible on the playground with version 1.95.0-nightly (2026-01-29 842bd5be253e17831e31)

[theemathas]

Another demonstration of the weirdness:

use std::marker::PhantomData;

struct Inv<'a>(PhantomData<fn(&'a ()) -> &'a ()>);

trait Trait<'a> {
    type Assoc;
    fn get(&self) -> Self::Assoc;
}

struct Thing;
impl<'a> Trait<'a> for Thing {
    type Assoc = Inv<'a>;
    fn get(&self) -> Inv<'a> {
        Inv(PhantomData)
    }
}

fn foo<'r>(_: &'r ()) -> impl use<'r> + 'static + Trait<'r, Assoc = Inv<'r>> {
    Thing
}

fn main() {
    let x;
    {
        let a = ();  // Suppose that this variable has lifetime 'a
        let b = foo(&a);
        x = b.get();
    }
    // The type of x is seemingly Inv<'a> 
    let x: Inv<'_> = x;  // works
    //let x: Inv<'static> = x;  // fails
}

[theemathas]

cc @lcnr

[theemathas]

Note: This was discovered after @SOF3 ran into the following weirdness in real code.

The following code compiles:

struct Foo(i32);
fn key<'a>(foo: &'a Foo) -> impl Ord + 'static + use<> { foo.0 }

fn list(s: &mut [Foo]) {
    s.sort_by_key(key);
}

However, removing the use<> (or equivalently, changing it to use<'a> causes the code to not compile in edition 2024:

struct Foo(i32);
fn key<'a>(foo: &'a Foo) -> impl Ord + 'static { foo.0 }

fn list(s: &mut [Foo]) {
    s.sort_by_key(key);
}

error[E0308]: mismatched types
   --> src/lib.rs:5:5
    |
  2 | fn key<'a>(foo: &'a Foo) -> impl Ord + 'static { foo.0 }
    |                             ------------------
    |                             |
    |                             the expected opaque type
    |                             the found opaque type
...
  5 |     s.sort_by_key(key);
    |     ^^^^^^^^^^^^^^^^^^ one type is more general than the other
    |
    = note: expected opaque type `impl for<'a> Ord + 'static`
               found opaque type `impl Ord + 'static`
    = note: distinct uses of `impl Trait` result in different opaque types
note: the lifetime requirement is introduced here
   --> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/slice.rs:249:25
    |
249 |         F: FnMut(&T) -> K,
    |                         ^

For more information about this error, try `rustc --explain E0308`.

[eggyal]

Isn't impl 'a + Trait<'b> covariant in 'a but invariant in 'b ?

[theemathas]

@eggyal Yes. I don't see how that contradicts anything here.

[QuineDot]

It's allowed due to PR #116733. The impl 'static means that the materially captured values cannot include non-'static lifetimes, and the (non-materially captured) use<'r> isn't considered for liveness.

If this can't produce UB with safe code, it is probably a form of soundness conflict. (Or was before the code was allowed if you want to look at it that way.) For example, trait object parameter lifetimes participate in liveness even when the erased type is 'static, and unsafe code could rely on that; this issue demonstrates you can't rely on that for trait objects opaque types (since the PR).

The sort_by_key error is because the lifetime is still captured in some sense. See the PR and its failed predecessor for more about why that is.

[QuineDot]

Without arguing for or against -> impl Trait trait parameters keeping borrows alive, I'll note that being able to mention a lifetime after a related borrowee has gone out of scope is not necessarily problematic.

Here is another example of a lifetime being valid to mention, even though it would be an error if the mention kept the borrow alive.

pub trait Trait {
    type Assoc<'a>: 'static;
    fn get(&self) -> Self::Assoc<'_>;
}

pub fn example<T: Trait>(t: T) {
    let x;
    {
        let t = t;
        x = t.get();
    }
    
    // This type cannot be normalized.
    let x: <T as Trait>::Assoc<'_> = x;

    // Errors:
    // let x: <T as Trait>::Assoc<'static> = x;
}

Here's another without a 'static bound. And in general, lifetimes can have holes which their associated borrows do not traverse, leading to situations where the lifetime can still be mentioned after a related borrowee has gone out of scope.

(Note also that variables like a in a previous comment or t in this example aren't assigned Rust lifetimes ('as) based on their drop scopes or the like.)

[theemathas]

@QuineDot Your code snippets seem to be instances of #128225 (comment)

I don't understand how any of this works...

[QuineDot]

Here's the OP rewritten to avoid impl Trait, demonstrating that it's behavior for aliases more generally.

// As before
struct Wrapper(core::ptr::NonNull<str>);
impl<'r> Into<&'r str> for Wrapper { /* ... unsafe ... */ }

trait Opaque<'r> {
    type Ty: 'static + Into<&'r str>;
    fn construct(r: &'r str) -> Self::Ty;
}

struct UniqueDefiningUse;
impl<'r> Opaque<'r> for UniqueDefiningUse {
    type Ty = Wrapper;
    fn construct(r: &'r str) -> Self::Ty {
        Wrapper(r.into())
    }
}

// Using a generic to ensure `G::Ty` cannot be normalized.
fn example<G: for<'r> Opaque<'r>>() {
    let a = G::construct(&String::from("huh"));
    let _unrelated = String::from("UB!");
    dbg!(a.into());
}

Compiles since 1.75 due to PR #116733.

See this comment for more background on the motivation for the PR.

[theemathas]

I'm finding some bizarre behavior...

Why does this code compile?

use std::marker::PhantomData;

trait Opaque<'r> {
    type Ty: 'static + Into<&'r str>;
    fn construct(r: &'r str) -> Self::Ty;
}

struct Wrap<T>(T);

fn example<G: for<'r> Opaque<'r>>() {
    let a = G::construct(&String::from("huh"));
    let b = G::construct(&String::from("wut"));
    let mut q = Wrap(make(&a));
    // deleting the line below makes the code stop compiling
    q = Wrap(same(make(&a), make(&b)));
    q.0 = make(&a);
    q.0 = make(&b);
}

fn same<T>(x: T, _: T) -> T { x }

fn make<'a>(_: &impl Into<&'a str>) -> Inv<'a> {
    PhantomData
}

type Inv<'a> = PhantomData<fn(&'a ()) -> &'a ()>;