This repository has been archived by the owner. It is now read-only.

Non-lexical lifetimes #16

Open
aturon opened this Issue Jan 31, 2017 · 10 comments

Comments

Projects
None yet
7 participants
@aturon
Member

aturon commented Jan 31, 2017

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.
@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Feb 1, 2017

Member

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

Member

aturon commented Feb 1, 2017

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

@pnkfelix

This comment has been minimized.

Show comment
Hide comment
@pnkfelix

pnkfelix Feb 10, 2017

Member

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

Member

pnkfelix commented Feb 10, 2017

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

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Feb 10, 2017

Member

@pnkfelix Gah! Done now.

Member

aturon commented Feb 10, 2017

@pnkfelix Gah! Done now.

@Manishearth

This comment has been minimized.

Show comment
Hide comment
@Manishearth

Manishearth Mar 3, 2017

Member

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

Member

Manishearth commented Mar 3, 2017

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

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Mar 3, 2017

Member

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

Member

aturon commented Mar 3, 2017

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

@pnkfelix

This comment has been minimized.

Show comment
Hide comment
@pnkfelix

pnkfelix Jun 7, 2017

Member

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

Member

pnkfelix commented Jun 7, 2017

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

@burdges

This comment has been minimized.

Show comment
Hide comment
@burdges

burdges Jun 10, 2017

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.

burdges commented Jun 10, 2017

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

This comment has been minimized.

Show comment
Hide comment
@vadixidav

vadixidav Jul 19, 2017

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

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

@christopherdumas

This comment has been minimized.

Show comment
Hide comment
@christopherdumas

christopherdumas Jul 23, 2017

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

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

@rfk rfk referenced this issue in mozilla/application-services May 2, 2018

Merged

Merge sync15 adapter #12

@BatmanAoD

This comment has been minimized.

Show comment
Hide comment
@BatmanAoD

BatmanAoD Jun 6, 2018

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.

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.