Non-lexical lifetimes

[aturon]

Point of contact

@pnkfelix @nikomatsakis

Tracking issue: rust-lang/rust#43234

Overview

See @nikomatsakis's blog posts (intro, NLL via liveness, the outlives relation) for an overview.

We want the lifetimes implicitly attached to borrows &expr to be refined, so that instead of being associated (sometimes loosely) with a lexical scope, each lifetime would now map to something else, (e.g. a set of points in the control-flow graph, though this alone is problematic unless it includes some context-sensitivity incorporating liveness)

A proposed design appears in a more recent blog series:

• NLL using liveness and location
• Nested method calls via two-phase borrowing

Status

(steps needed for NLL and their current status)

• Develop model for static semantics of non-lexical lifetimes. (E.g. what do lifetimes denote, how do following work: subtyping, region-inference, type- and borrow-checking.)
• Add NLL encoding of lexical lifetimes to MIR (EndRegion statements) rust-lang/rust#39409
• Port borrow-checker to MIR (in progress, current branch needs rebasing, fixing, factoring into smaller pieces for landing)
• Add NLL region inference, revising location of EndRegion statements and allow more (sound) code through.

[aturon]

@pnkfelix Can you flesh out this issue with a paragraph or two of overview, and some bullets for the status?

[pnkfelix]

@aturon can you give me edit access to the issue description?

[aturon]

@pnkfelix Gah! Done now.

[Manishearth]

(Please restrict comments to discussions about how to achieve the goal and for tracking progress towards the goal)

[aturon]

Updates: a basic design is being proposed in a new blog series:

• NLL using liveness and location
• Nested method calls via two-phase borrowing

[pnkfelix]

Updates: added notes regarding EndRegion and the port of borrowck to MIR.

[burdges]

I've occasionally run into with a function like f(&mut T) -> &Result<&T> { ..; Ok(self) }. In other words, there is a mutable borrow that gives rise to an immutable borrow, but the borrow checker cannot treat the final borrow as immutable because it cannot know if you've hidden the &mut T behind interior mutability. We could perhaps address this with some form of auto-trait Mutates<T> but doing so sounds way nastier, and far more dangerous, than any of the Send/Sync confusion.

[vadixidav]

@pnkfelix Your branch seems to have been silent for a while. Are there any blockers here and what is the current status?

[christopherdumas]

@vadixidav I've been just watching from afar here, but it looks like (according to the Rust Blog) the design is not quite complete enough to finish implementing?

[BatmanAoD]

FYI, this issue is still one of the top Google results for "rust non-lexical lifetimes" and variations thereof. It might be good to link to rust-lang/rust#43234 or something in the top comment.