NLL: named lifetimes in closures can be unrelated to those in parent function

[aliemjay]

Update: I originally thought it's a soundness issue, but it may not be, see comment #98589 (comment).

This code compiles after #95565 although it shouldn't: (playground)

fn lives_as_long<'a, T>() where T: 'a, {}

fn test<'a, T>()
where
    &'a (): Sized, // any predicate containing `'a`
{
    || {
        lives_as_long::<'a, T>();
    };
}

@rustbot label C-bug T-types regression-from-stable-to-nightly I-unsound A-NLL

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-critical

[steffahn]

I have yet to find a way to exploit this code for actual unsound behavior. Perhaps you know a way @aliemjay? Preliminary experiments make it seem … possibly … more as if the lives_as_long::<'a, T>() call kinda ignores the explicit 'a and infers a shorter lifetime instead.

[steffahn]

E.g. this works

use std::fmt::Display;

fn lives_as_long<'a, T: Display>(x: T) -> Box<dyn Display + 'a>
where
    T: 'a,
{
    Box::new(x)
}

fn test<'a, T: Display>(x: T)
where
    &'a (): Sized, // any predicate containing `'a`
{
    let f = |x: T| -> Box<dyn Display + 'a> { lives_as_long::<'a, T>(x) };
    let r: Box<dyn Display + '_> = f(x); // <- inferred short lifetime for '_
}

but this doesn’t

use std::fmt::Display;

fn lives_as_long<'a, T: Display>(x: T) -> Box<dyn Display + 'a>
where
    T: 'a,
{
    Box::new(x)
}

fn test<'a, T: Display>(x: T)
where
    &'a (): Sized, // any predicate containing `'a`
{
    let f = |x: T| -> Box<dyn Display + 'a> { lives_as_long::<'a, T>(x) };
    let r: Box<dyn Display + 'a> = f(x); // <- explicit lifetime 'a from the function signature
}

error[E0309]: the parameter type `T` may not live long enough
  --> src/lib.rs:14:13
   |
14 |     let f = |x: T| -> Box<dyn Display + 'a> { lives_as_long::<'a, T>(x) };
   |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ...so that the type `T` will meet its required lifetime bounds
   |
help: consider adding an explicit lifetime bound...
   |
10 | fn test<'a, T: Display + 'a>(x: T)
   |                        ++++

---

Same story with

fn test<'a, T: Display>(x: T)
where
    &'a (): Sized, // any predicate containing `'a`
{
    let mut r: Option<Box<dyn Display + '_>> = None; // <- inferred short lifetime for '_
    let f = |x: T| {
        r = Some(lives_as_long::<'a, T>(x));
    };
}

vs

fn test<'a, T: Display>(x: T)
where
    &'a (): Sized, // any predicate containing `'a`
{
    let mut r: Option<Box<dyn Display + 'a>> = None; // <- explicit lifetime 'a from the function signature
    let f = |x: T| {
        r = Some(lives_as_long::<'a, T>(x));
    };
}

error[E0309]: the parameter type `T` may not live long enough
  --> src/lib.rs:15:13
   |
15 |       let f = |x: T| {
   |  _____________^
16 | |         r = Some(lives_as_long::<'a, T>(x));
17 | |     };
   | |_____^ ...so that the type `T` will meet its required lifetime bounds
   |
help: consider adding an explicit lifetime bound...
   |
10 | fn test<'a, T: Display + 'a>(x: T)
   |                        ++++

[steffahn]

I feel like the “predicate containing 'a” makes 'a early-bound instead of late-bound which is probably what makes “a difference” here in terms of compiler behavior.

[jackh726]

Early-bound vs late-bound makes sense for the change in behavior

[steffahn]

I’m increasingly convinced that this is not really a soundness issue. The behavior is confusing though, so it is an issue. It’s almost as if the closure struct implementing the closure (which would be necessarily generic over the lifetimes it “captures” if implemented manually) did not get instantiated with the right lifetimes, but instead those were left inferred. I.e.

fn lives_as_long<'a, T>() where T: 'a, {}

fn test<'a, T>()
where
    &'a (): Sized, // any predicate containing `'a`
{
    || {
        lives_as_long::<'a, T>();
    };
}

would turn into something like

fn lives_as_long<'a, T>() where T: 'a, {}

fn test<'a, T>()
where
    &'a (): Sized, // any predicate containing `'a`
{
    struct Closure<'a, T>(…) where T: 'a;
    impl<'a, T> FnOnce<…> for Closure<'a, T> { … } // and also FnMut and Fn

    Closure::<'a, T>(…);
}

if implemented by hand, but it currently behaves as if instead of Closure::<'a, T>(…); something like Closure::<'_, T>(…); is used, leaving the lifetime inferred/unspecified, and meaning that an error due to the T: 'a constraint only appears if the calls (or other usages of the closure) put bounds on that inferred lifetime that are in conflict with the fact that T: 'a is not true.

[aliemjay]

I agree that this is most likely not a soundness issue, but it's still confusing and fixing it in the future would be a breaking change.

By looking closer at the source, the named lifetime 'a that appears in the closure is indeed a free inference variable independent from the 'a found in the defining scope. It behaves similarly to how @steffahn theorized in the previous comment.

Perhaps this counts an unintended stabilization. Re-requesting prioritization in light of this.

@rustbot label -I-unsound +I-prioritize