Can mutate in match-arm using a closure

[arielb1]

Update from pnkfelix: Note that this is now fixed by NLL (see #50783). This bug just remains open because @pnkfelix thinks our policy is to keep NLL-fixed-by-NLL bugs open until we make NLL the default for rustc.

---

STR

fn main() {
    match Some(&4) {
        None => {},
        ref mut foo
            if {
                (|| { let bar = foo; bar.take() })();
                false
            } => {},
        Some(s) => println!("{}", *s)
    }
}

Actual Results

playpen: application terminated abnormally with signal 4 (Illegal instruction)

[eefriedman]

Ideally, the type of "foo" in the pattern guard should be &Option<&i32> rather than &mut Option<&i32>... then we could loosen the overly restrictive mutation rules in pattern guards.

We might be able to specifically check for this case at

rust/src/librustc/middle/check_match.rs

Line 1144 in d38e8a0

fn check_for_mutation_in_guard<'a, 'tcx>(cx: &'a MatchCheckCtxt<'a, 'tcx>,

; the problem there is that it could end up spuriously detecting a mutable borrow.

Another possibility would be to make it impossible to move out of variables of type &mut _; this is probably something we want to do anyway to eliminate the distinction between let bar = foo; (which moves) and let foo : &mut _ = foo (which reborrows).

[steveklabnik]

This compiles with no error today. Nominating.

[arielb1]

Fix by MIR borrowck. Forgot to tag as I-unsound myself.

[pnkfelix]

Oddly this seems to be on the road to be fixed (as in flagged as error) by -Z borrowck=mir, but then when you add -Z nll to the mix, the error is again missed.

[nikomatsakis]

The NLL analysis not wrong exactly, but there is a kind of implicit borrow that's not manifest in the MIR. In particular, the NLL analysis determines that the ref mut foo is only used in one particular basic block, and hence there are no overlapping uses of the value being matched.

That is, the MIR is sort of doing piecemeal tests that read the value of the option, but assuming that the option will not change in the meantime. We can guarantee that it won't by taking a borrow, but we don't do that. So effectively we get this:

let mut v = Some(4);

if v.is_none() { ... }

let mut p = &mut v;
(|| { p.take(); () })(); // clears `v`

let s = v.unwrap(); // panics here, but UB in MIR

except that the final unwrap() would be UB.

At least that's how I read it now.

[pnkfelix]

for now I'm labelled this with the NLL labels. We may not be able to include a fix for this in the initial release, but it would be nice to try...

[nikomatsakis]

Seems like we have to fix this. I'm not sure just what the best way is -- but I think we have to represent the "implicit borrow" in the MIR.

[pnkfelix]

Assigning to self and up'ing priority to P-high to reflect severity for deploying NLL.

[pnkfelix]

I am currently exploring extending MIR with a way to express "borrow all the discriminants reachable from place" so that we can freeze the variant alone over the course of all patterns+guards for a given match. Hopefully that can address this bug.

[nikomatsakis]

@pnkfelix I've been having second thoughts on that approach. For example, consider this:

let mut b = true;
match b {
    true => ...
    false => ...
}

no "discriminant" is touched, but we want to know that no writes occur.

I think we should think again about idea of shared borrow of the entire value being matched and then having guards access their bindings through a &T (where T is the user-visible type of the binding). To handle ref mut bindings, we can consider creating (for the guard) a ref binding and using a cast to coerce the &'a &'a T to a &'a &'a mut T (which I believe are identical in power anyhow).

That last part is a hack, no question, but overall the approach is pretty elegant, and seems like it would cover all cases.

Thoughts?

[pnkfelix]

Seems like my suggestion (from our private conversation) of an explicit EndBorrow would also handle the case you mention

But I’m willing to try your suggestion. Either direction has some hackery to it

[pnkfelix]

(but I am going to remove it from the "NLL invalid code does not compile" milestone because it is fixed by NLL... Update: ah niko is too quick for me.)

[pnkfelix]

NLL (migrate mode) is enabled in all editions as of PR #59114.

The only policy question is that, under migrate mode, we only emit a warning on this (unsound) test case. Therefore, I am not 100% sure whether we should close this until that warning has been turned into a hard-error under our (still in development) future-compatibility lint policy.