Moves in guard expressions aren't handled properly

[Aatch]

This code causes a segfault (without optimisations on):

use std::fmt;
fn main() {
    let a = std::rc::Rc::new(1);

    let x = (1, 2);

    match x {
        (_, y) |
        (y, _) if take(y, a) => (),
        _ => ()
    }

}

fn take<T:fmt::Debug>(x: usize, t: T) -> bool {
    println!("{:?}", t);
    x == 1
}

as does this similar code:

use std::fmt;
fn main() {
    let a = std::rc::Rc::new(1);

    let x = (1, 2);

    match x {
        (_, y) if take(y, a) => (),
        (y, _) if take(y, a) => (),
        _ => ()
    }

}

fn take<T:fmt::Debug>(x: usize, t: T) -> bool {
    println!("{:?}", t);
    x == 1
}

This is because the current control flow graph essentially visits each arm in parallel. With multiple patterns, each pattern within the arm is visited, then the guard is visited after all the patterns have been visited, even though this doesn't reflect the real semantics (we visit the pattern, then the guard, then the next pattern, then the guard again).

[Aatch]

I'm working on a fix for both of these issues. Should be done fairly soon I hope.

[pnkfelix]

@Aatch whoa, I thought we didn't support moves into guards in the first place?

(That is, not that I object to you fixing this ... but I had thought there was an explicit decision not to support such guards, at least not in the short term, because we were not confident we could make it work!)

Am I mistaken?

[Aatch]

@pnkfelix Well I managed to get it to work (you're actually assigned to the PR fixing it). You may be thinking of mutation in guards though, since that's disallowed.

[pnkfelix]

@Aatch ah that is what I was thinking of, indeed. (My mind isn't made up about whether it makes sense to support moves into guards; if we got away with disallowing mutation, why not moves as well, at least for the short term.)

[pnkfelix]

1.0 beta, P-backcompat-lang.

[pnkfelix]

(this comment was accidentally posted here, and has moved to: #22075 (comment) )