error[E0597]: `x` does not live long enough

The exact error string

error[E0597]: `local_name` does not live long enough
 --> src/main.rs:3:26
  |
2 |     let local_name = String::from("Ada");
  |         ---------- binding `local_name` declared here
3 |     return &local_name;
  |             ^^^^^^^^^^ borrowed value does not live long enough
4 | }
  | - `local_name` dropped here while still borrowed

Every E0597 message names the value, the line it was declared on, the line the borrow occurs, and — critically — the exact line where the value is dropped while a reference to it is still expected to be valid. That last line is the key: it tells you precisely where the value's scope ends relative to where the reference is still needed.

The scope-vs-lifetime mismatch, visually

Cause 1: returning a reference to a local variable

fn make_name() -> &str {
    let local_name = String::from("Ada");
    &local_name   // ❌ local_name is dropped when the function returns
}

// ✅ return the owned value itself — ownership transfers to the caller,
//    so there's nothing to outlive:
fn make_name() -> String {
    let local_name = String::from("Ada");
    local_name
}

This is the unconditional, unfixable-by-annotation version of the error: a local variable's storage belongs to its enclosing function's stack frame, which is torn down the instant the function returns. There is no lifetime you can write that makes a reference to freed stack memory valid — the only real fix is to stop trying to hand out a reference at all and return the owned value, transferring ownership to the caller instead of pointing at something about to disappear.

Cause 2: a struct holding a reference that outlives its source

struct Wrapper<'a> { name: &'a str }

fn build() -> Wrapper<'static> {
    let s = String::from("Ada");
    Wrapper { name: &s }   // ❌ `s` does not live long enough
}   // `s` dropped here, but Wrapper claims to hold a 'static reference

// ✅ store an owned String instead of borrowing:
struct Wrapper { name: String }
fn build() -> Wrapper {
    let s = String::from("Ada");
    Wrapper { name: s }
}

A struct with a lifetime parameter is making a promise: every reference it holds must remain valid for at least as long as the struct itself is used. When the struct is built from a value local to the function that's supposed to hand the struct back out, that promise is impossible to keep — the reference inside would need to outlive the local variable it points to. Storing owned data (a String instead of a &str) sidesteps the whole problem by giving the struct its own copy of the data rather than a view into someone else's, at the cost of the extra allocation.

Cause 3: a temporary value dropped at the end of its statement

let first_word: &str = "hello world".split(' ').collect::<Vec<_>>()[0];
// ❌ the Vec from .collect() is a temporary — dropped at the end of this
//    statement, taking its contents' backing storage with it

// ✅ bind the temporary to a name first, extending its scope:
let words: Vec<&str> = "hello world".split(' ').collect();
let first_word: &str = words[0];

An intermediate value produced mid-expression — the result of a chained method call that's never bound to a variable — is a temporary, and Rust drops temporaries at the end of the statement they're created in unless something extends their scope. Taking a reference into a temporary's contents and trying to use that reference past the end of the statement runs into exactly the same not-living-long-enough problem as any other value; giving the temporary an explicit name via let is what extends its lifetime to cover the rest of that variable's own scope.

Cause 4: a mutex/lock guard dropped before its reference is used

use std::sync::Mutex;
let data = Mutex::new(vec![1, 2, 3]);

let first = &data.lock().unwrap()[0];   // ❌ the MutexGuard temporary is
                                          //    dropped at the end of this line
println!("{}", first);

// ✅ bind the guard to a name so it stays alive for the block:
let guard = data.lock().unwrap();
let first = &guard[0];
println!("{}", first);

Calling .lock() returns a guard object (whose Drop implementation releases the lock), and if that guard is never bound to a name, it's a temporary that gets dropped at the end of its statement — releasing the lock and invalidating any reference taken into the locked data at the exact same moment. This is a specific, common instance of Cause 3 that trips up developers working with concurrency primitives specifically, since the error can look like a completely unrelated E0597 rather than an obviously-temporary-related mistake.

Common causes at a glance

Why this happens: Rust checks scopes against reference needs at compile time

The borrow checker's job for this class of error boils down to one comparison, repeated everywhere a reference exists in a program: does the value being referenced remain alive for at least as long as the reference to it is used? A value's scope ends deterministically — at the closing brace of the block it was declared in, or at the end of a statement if it's an unbound temporary — and the compiler computes exactly how long each reference needs to remain valid based on how it's used afterward (returned, stored in a struct, held across a lock). E0597 fires the moment those two spans don't nest correctly: the reference's required span extends past the value's actual span. This is precisely the compile-time analysis that eliminates dangling-pointer bugs, one of the most common and dangerous classes of memory-safety defects in languages like C and C++, at zero runtime cost — the entire check happens during compilation and produces no code in the final binary.

Debugging checklist

• ✓ Find the "dropped here while still borrowed" line — that's exactly where the value's scope ends
• ✓ If you're returning a reference to something declared inside the function, return owned data instead
• ✓ If a struct holds a reference, consider whether it should own the data instead
• ✓ If the borrow is into a chained method-call result, bind the intermediate value to a let first
• ✓ Working with a Mutex/RwLock? Bind the guard to a named variable before borrowing into it