Lifetime error sometimes shows a misleading root cause

[purplesyringa]

Code

fn good1<'a>(value: &'a str) -> &'static str {
    value
}

fn good2<'a>(value: &'a str) {
    core::convert::identity::<&'static str>(value);
}

fn bad1<'a>(value: &'a str) {
    let _p: &'static str = value;
}

use core::marker::PhantomData;
fn bad2<'a>(value: &'a str) {
    let phantom = PhantomData::<*mut &'static str>;
    unify(phantom, value);
}
fn unify<T>(_phantom: PhantomData<*mut T>, _value: T) {}

Current output

error: lifetime may not live long enough
 --> src/lib.rs:2:5
  |
1 | fn good1<'a>(value: &'a str) -> &'static str {
  |          -- lifetime `'a` defined here
2 |     value
  |     ^^^^^ returning this value requires that `'a` must outlive `'static`

error[E0521]: borrowed data escapes outside of function
 --> src/lib.rs:6:5
  |
5 | fn good2<'a>(value: &'a str) {
  |          --  ----- `value` is a reference that is only valid in the function body
  |          |
  |          lifetime `'a` defined here
6 |     core::convert::identity::<&'static str>(value);
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |     |
  |     `value` escapes the function body here
  |     argument requires that `'a` must outlive `'static`

error: lifetime may not live long enough
  --> src/lib.rs:10:13
   |
9  | fn bad1<'a>(value: &'a str) {
   |         -- lifetime `'a` defined here
10 |     let _p: &'static str = value;
   |             ^^^^^^^^^^^^ type annotation requires that `'a` must outlive `'static`

error: lifetime may not live long enough
  --> src/lib.rs:15:19
   |
14 | fn bad2<'a>(value: &'a str) {
   |         -- lifetime `'a` defined here
15 |     let phantom = PhantomData::<*mut &'static str>;
   |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ assignment requires that `'a` must outlive `'static`
   |
   = note: requirement occurs because of a mutable pointer to `&str`
   = note: mutable pointers are invariant over their type parameter
   = help: see <https://doc.rust-lang.org/nomicon/subtyping.html> for more information about variance

Desired output

error: lifetime may not live long enough
 --> src/lib.rs:2:5
  |
1 | fn good1<'a>(value: &'a str) -> &'static str {
  |          -- lifetime `'a` defined here
2 |     value
  |     ^^^^^ returning this value requires that `'a` must outlive `'static`

error[E0521]: borrowed data escapes outside of function
 --> src/lib.rs:6:5
  |
5 | fn good2<'a>(value: &'a str) {
  |          --  ----- `value` is a reference that is only valid in the function body
  |          |
  |          lifetime `'a` defined here
6 |     core::convert::identity::<&'static str>(value);
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |     |
  |     `value` escapes the function body here
  |     argument requires that `'a` must outlive `'static`

error: lifetime may not live long enough
  --> src/lib.rs:10:13
   |
9  | fn bad1<'a>(value: &'a str) {
   |         -- lifetime `'a` defined here
10 |     let _p: &'static str = value;
   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |     |
   |     type annotation requires that `'a` must outlive `'static`

error: lifetime may not live long enough
  --> src/lib.rs:15:19
   |
14 | fn bad2<'a>(value: &'a str) {
   |         -- lifetime `'a` defined here
15 |     let phantom = PhantomData::<*mut &'static str>;
16 |     unify(phantom, value);
   |     ^^^^^^^^^^^^^^^^^^^^^^
   |     |
   |     `value` escapes the function body here
   |     argument requires that `'a` must outlive `'static`
   |
   = note: requirement occurs because of a mutable pointer to `&str`
   = note: mutable pointers are invariant over their type parameter
   = help: see <https://doc.rust-lang.org/nomicon/subtyping.html> for more information about variance

Rationale and extra context

It's strange that the span sometimes points at the type or expression that implies the 'static bound, rather than at the expression that doesn't satisfy the 'static bound. It seems to me that it'd be more correct to always point at the value/type with the shortest lifetime first, and then at the reason why that lifetime was insufficient second.

good1 and bad1 are very similar: in both cases, a value is checked against a type annotation. But while good1 points at the expression with a too-short lifetime, bad2 spells nonsense like "type annotation requires that 'a must outlive 'static" -- at the very least, the type annotation doesn't require anything, value being assigned to a variable of this type does.

In good2 and bad2, it's inconsistent that f::<'static>(value) believes value is the problem, while f([a marker struct with a 'static lifetime parameter], value) is angry at the marker struct, even though in both cases, the lifetime bound is semantically provided "out of band". Replacing let with const in bad2 results in much better output, though obviously only because of changes in type inference.

My main problem with the current diagnostic is that, if a variable is assigned multiple times or a marker struct is used in multiple unify calls, it's impossible to find exactly which assignment or call caused the issue.

Other cases

Rust Version

rustc 1.90.0-nightly (a00149764 2025-07-14)
binary: rustc
commit-hash: a001497644bc229f1abcc5b2528733386591647f
commit-date: 2025-07-14
host: x86_64-unknown-linux-gnu
release: 1.90.0-nightly
LLVM version: 20.1.8

Anything else?

No response

[purplesyringa]

There's also this example... but I don't know exactly how related it is.

use std::marker::PhantomData;

fn f<'a>(s: &'a str) -> impl FnOnce() -> &'static str {
    let phantom = PhantomData::<*mut &'static str>;
    move || unify(phantom, s)
}

fn unify<T>(_phantom: PhantomData<*mut T>, _value: impl Trait<T>) -> T {
    loop {}
}

trait Trait<T> {}
impl<T> Trait<T> for T {}

error: lifetime may not live long enough
 --> src/lib.rs:5:5
  |
3 | fn f<'a>(s: &'a str) -> impl FnOnce() -> &'static str {
  |      -- lifetime `'a` defined here
4 |     let phantom = PhantomData::<*mut &'static str>;
5 |     move || unify(phantom, s)
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^ returning this value requires that `'a` must outlive `'static`
  |
help: to declare that `impl FnOnce() -> &'static str` captures data from argument `s`, you can add an explicit `'a` lifetime bound
  |
3 | fn f<'a>(s: &'a str) -> impl FnOnce() -> &'static str + 'a {
  |                                                       ++++

So rustc realizes something is off with lifetimes when typechecking the closure, rather than the unify call. But that's weird -- the unify call should've failed first (or, at least, it's more likely the root cause). I guess you could argue that typeck can see through the signature of unify and infer T from the type of s rather than phantom (though I tried to obfuscate it with APIT -- I guess it didn't work?), but it's still weird from the user perspective.

[dianne]

These all sound like problems with best_blame_constraint's current heuristics.

• In bad1, it could pick the Assignment constraint instead of the TypeAnnotation constraint, but it's not currently smart enough to tell that that would be better. Possibly for type ascriptions on assignments, it should prioritize blaming the Assignment constraint instead.
• For bad2, iirc (this could be wrong; it's been a while since I last looked at it) we usually try to blame a constraint as close as we can to the region that must be outlived. This works great for simple covariant examples like good1 and good2 where it's in some "expected" type (like the return type or an argument type in those examples); those are very helpful to blame. But in bad2, because of *mut's invariance, the region that must be outlived is introduced in the definition of phantom, so that's what gets blamed instead.
• The behavior in the f example shows off a partial workaround for that: it blames the return because it tends to be close to right, even though it's not always the best thing to blame.