NLL allows creating variables that are immediately unusable.

[matthewjasper]

The following code compiles with NLL currently

fn main() {
    let x = {
        let z = 0;
        &z
    };
}

because it's equivalent to:

fn main() {
    let x;
    {
        let z = 0;
        x = &z
    };
}

However, any further use of x will result in a "z does not live long enough" warning. Should there be some read of x after the rest of the let is done to ensure that this doesn't happen?

[pnkfelix]

I suppose since we already have ReadForMatch (which is essentially an over-approximation of what a given pattern in a match may do, and thus I think of it as a "fake read"), that provides some precedent for trying to add some sort of fake read in this scenario too... I guess the idea is that we'd put it immediately after each let statement...?

[pnkfelix]

(nominating in the hopes that the WG-compiler-nll team will discuss this. Though its possible that the decision needs to be with T-compiler. ((or even T-lang??)))

[pnkfelix]

(I also wonder if adding a fake read for every local will fix some of the issues we've seen with the compiler accepting "surprising" cases where the issue was that a closure was constructed but never called.)

[matthewjasper]

Weren't those issues with AST borrowck?

[pnkfelix]

@matthewjasper well, I was thinking of the cases where I had to add explicit references to a local variable in order to observe a desired unit test failure. Let me find the link...

[pnkfelix]

@matthewjasper i.e I was thinking of things like this: https://github.com/rust-lang/rust/pull/53407/files#diff-11c4698b7f13fd531c6a5a7b78f27d27R57

Update: oops, sorry I meant https://github.com/rust-lang/rust/pull/53407/files?utf8=%E2%9C%93&diff=split#diff-11c4698b7f13fd531c6a5a7b78f27d27R58

[pnkfelix]

After discussion at the WG-compiler-nll meeting, the participants agreed that while we (and possibly T-compiler/T-lang) do need to make some decision here, it does not need to be made in time for the RC milestone.

So I changed the milestone on this ticket to RC2.

[pnkfelix]

Visited by compiler team. Reassigning to T-lang team.

[joshtriplett]

We discussed this in the lang team meeting, and felt that the existing warning lints (such as for unused variables or for a value assigned and never used) seem sufficient to cover this case.

[nikomatsakis]

Discussed in the @rust-lang/lang team meeting. General consensus was that as long as this is not harmful, it seems ok to permit it. There are already lints (e.g., unused_variable) that apply.

https://play.rust-lang.org/?gist=4b1b499e59fdf4d3e377389da016e987&version=nightly&mode=debug&edition=2015

https://play.rust-lang.org/?gist=287d0f0b0eca80ce54f1d40e2ab12975&version=nightly&mode=debug&edition=2015

EDIT: @joshtriplett jinx!

[nikomatsakis]

@matthewjasper raised an interesting point on Zulip that I think is worth preserving. In particular, we were discussing how, in MIR, we desugar:

let PAT = EXPR

into something like:

• Evaluate EXPR into a temporary TMP
• Destructure TMP into the pattern PAT

But in the case of a trivial pattern like x, we just evaluator EXPR directly into x.

It is in fact this final step -- evaluating directly into x -- that permits this case to type-check, since otherwise there would be an access after EXPR has been fully evaluated (and the block terminated).

I'm not sure if this bothers me, but it's interesting.

As an example, this does not compile, even with NLL (playground):

#![feature(nll)]

fn main() {
    let (x,) = {
        let z = 0;
        (&z,)
    };
}

[nikomatsakis]

@pnkfelix and I discussed on Zulip. Our feeling is that there may be more complications here as well and therefore that we ought to try to make this change as an experiment — if the disruption is minimal, it seems good to try and future proof here, but we might also decide to back off.

[nikomatsakis]

I think we basically just want to insert a statement around here:

rust/src/librustc_mir/build/matches/mod.rs

Line 258 in f17c230

self.schedule_drop_for_binding(var, irrefutable_pat.span, OutsideGuard);

Specifically, a ReadForMatch reading the newly created binding.

[nikomatsakis]

Discussed in the lang team meeting. We decided that it makes sense to give an error here; the "official MIR lowering" ought to be that the RHS is evaluated and then moved into the pattern, and hence there is a use that comes after the RHS has been evaluated, and an error is warranted (we happen to optimize this in MIR generation, but that shouldn't necessarily be observable).