Variables moved from in match guards are still accessible in other match arms.

The following code segfaults at runtime on stable, beta, and nightly:

fn main() {
    let x = 10;
    let s = Custom { val: Vec::new() };

    match x {
        10 if test(s) => println!("oops"),
        _ => println!("eek {:?}", s.val),
    }
}

#[derive(Debug)]
pub struct Custom {
    val: Vec<u8>,
}

impl Drop for Custom {
    fn drop(&mut self) { println!("Dropping"); }    
}

#[allow(unused_variables)]
fn test(s: Custom) -> bool { false }

Possibly aided by #3478?

[eddyb]

Shorter testcase:

fn main() {
    let s = String::new();
    let _s = match 0 {
        0 if { drop(s); false } => String::from("oops"),
        _ => {
            // This should trigger an error,
            // s could have been moved from.
            s
        }
    };
}

CFG for this testcase:

[eddyb]

cc @rust-lang/compiler

This would be solved by the MIR, right?
The way match guards would be desugared in the MIR, they would be potential ancestors of following match arms, and a MIR borrowck wouldn't be able to miss them.

[LLBlumire]

Bringing mine and @eddyb 's IRC conversation into here for readability.

The issue is that the path on the left in the image above does not chain into the path on the right, meaning that drop(s) can be followed by { s }.

This seems to be a configuration issue in https://github.com/rust-lang/rust/blob/master/src/librustc/middle/cfg/construct.rs#L429-L529

[arielb1]

Wait can you move in guards?

[Manishearth]

@arielb1 you shouldn't be able to

[Aatch]

Hmm, looks like I missed this case when I fixed a very similar issue (moving in multiple guard expressions). The issue is that the way the final guard is handled means that it acts as if it can't fail. Wiring up the contents of prev_guards to arm exit in the case where the arm has no guard and no bindings (including wildcard) should fix it. It should also do the same at the very end, adding edges from the remaining guards to the exit of the match expression.

@Manishearth I tried disallowing it, but there's some code around that moves in guards. Its also a breaking change.

[Aatch]

Ok, in trying to fix this I ran into an issue that is probably why I didn't handle this case last time. Borrows due to by-ref bindings in matches are scoped the match expression itself, meaning that something like:

match foo_opt {
  Some(ref foo) if cond => { ... }
  None => { foo_opt.val = bar; }
}

will complain that you can't assign to foo_opt.val because it's already borrowed (which is clearly not true). It's essentially the canonical example for the kind of thing SEME will solve, except worse.

[bstrie]

@eddyb How did you get rustc to spit out the CFG like that?

@bstrie rustc file.rs -Z unstable-options --unpretty flowgraph=main > out.dot