dropck: track order of destruction for r-value temporaries

[pnkfelix]

Spawned off of #21022, #21972; see also #21657.

Tracking order of destruction for r-value temporaries would (probably) allow us to resume writing code like this from RFC 769:

for line in old_io::stdin().lock().lines() {
    ...
}

which is currently disallowed because the region inference system does not know that the temporary yielded by stdin() will outlive the temporary from stdin().lock().

(But note that it might also have fallout, potentially worse than that of #21657)

[pnkfelix]

cc #22321

[steveklabnik]

Triage: not aware of any changes here, but it's also not an area I'm super familiar with.

[pnkfelix]

I assume MIR and non lexical lifetimes will likely resolve this directly

[pnkfelix]

According to

rust/src/test/ui/span/issue-23338-locals-die-before-temps-of-body.nll.stderr

Line 1 in 54628c8

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

this does not appear to be fixed by NLL.

Update (circa September 2018): Oh, that test is an instance of #46413, not this.

[pnkfelix]

(which is ... okay, but a little surprising, and perhaps worth investigation after we've taken care of the other bigger problems in NLL.)

[pnkfelix]

I'm just going to throw in a reference to the NLL tracking issue #43234 in the hopes that we remember to look at this again later.

[pnkfelix]

I just want to make two quick notes:

• As part of MIR-borrowck we did make a language "change" to track destruction order of locals declared in the same let-binding, which was something we previously treated as having an unspecified destruction order in the borrow-checker...
• I would have thought that MIR-borrowck would have "fixed" this issue (dropck: track order of destruction for r-value temporaries #22323) simply by its architecture. Which is why I have comments like dropck: track order of destruction for r-value temporaries #22323 (comment)

[pnkfelix]

Putting onto the Release milestone in the hopes that this forces me to take action here.

[pnkfelix]

I investigated. NLL does fix the problem described in this issue.

My earlier comments regarding cases that don't work are instances of misclassification on my part; they should have been associated with #46413 and perhaps #21114

[pnkfelix]

Visited for T-compiler triage. Removing NLL-fixed-by-NLL issues from the Release milestone, but continue to leave them open as issues themselves.