Non-lexical lifetimes

Question

Non-lexical lifetimes

aturon opened this issue 8 years ago · 10 comments

aturon commented 8 years ago

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:

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.

Answer 1 · 2017-02-01T18:30:04.000Z

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

Answer 2 · 2017-02-10T16:24:48.000Z

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

Answer 3 · 2017-02-10T16:34:32.000Z

@pnkfelix Gah! Done now.

Answer 4 · 2017-03-03T07:58:08.000Z

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

Answer 5 · 2017-03-03T14:00:36.000Z

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

Answer 6 · 2017-06-07T16:05:52.000Z

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

Answer 7 · 2017-06-10T05:45:54.000Z

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.

Answer 8 · 2017-07-19T00:58:42.000Z

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

Answer 9 · 2017-07-23T01:20:50.000Z

@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?

Answer 10 · 2018-06-06T20:33:57.000Z

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.