Implement Pattern Guards with Bind-By-Move

[alexcrichton]

Tracking issue for "Pattern Guards with Bind-By-Move" (rust-lang/rfcs#107)

Steps:

• Implement the RFC (already done as part of NLL work)
• Adjust documentation (see instructions on forge)
• Stabilization PR (see instructions on forge)

[steveklabnik]

Triage: this has still not been implemented

[jonhoo]

I keep running into this (or rather, the simpler #14252) in places where I now end up with an extra level of indentation:

match x {
    Foo(v) => if do_a {
            // ...
        } else if do_b {
            // ...
        } else if do_c {
            // ...
        } else {
            // ...
        }
}

when it could be

match x {
    Foo(v) if do_a => {
        // ...
    },
    Foo(v) if do_b => {
        // ...
    },
    Foo(v) if do_c => {
        // ...
    },
    Foo(v) => {
        // ...
  }
}

[pnkfelix]

(i believe this feature is effectively implemented by NLL, namely as PR #49870. I should probably port any examples, including corner case examples noted on PR #42088, to the NLL test suite just to make sure.)

[pnkfelix]

Actually perhaps the right thing for me to do would be to put in the feature(bind_by_move_pattern_guards) and then have that, when NLL is enabled, be the thing that toggles what is currently controlled by -Z disable_ast_check_for_mutation_in_guard

[pnkfelix]

Now that PR #54034 has landed, I'm unassigning myself.

(But, if I understand correctly, the issue should stay open until feature(bind_by_move_pattern_guards) gets stabilized)

[pnkfelix]

(I guess it would be good to remove the -Zdisable-ast-check-for-mutation-in-guard flag and replaces uses of it in our test suite with #![feature(bind_by_move_pattern_guards)])

[pnkfelix]

unassigning this from myself; I've done the porting to the NLL test suite, but I have higher priority things on my plate to take care of before I go on leave.

(I invite anyone to come and pick up the torch for following through on the remaining steps here!)

[pnkfelix]

since this is implemented and all that remains is 1. making NLL the default everywhere and then 2. stabilizing the feature, I'll let this be handled by T-lang alone now, not T-compiler.

• step 1 might even be optional, if we're willing to stabilize this feature solely on editions >= 2018 for now.

[Centril]

Nominated for next T-lang meeting to see how we want to proceed, specifically re. @pnkfelix's note re. step 1.

[nikomatsakis]

In principle I guess stabilizing for Rust 2018 is fine. I'm not sure how much impl complexity that results in -- if nothing else it means more complex branches. I'm a bit wary.

[nikomatsakis]

I guess in general I would rather wait until NLL has proceeded further down the stability path to take action here. In particular, I'd like to see NLL enabled on all editions first and without any "outstanding questions", essentially (e.g. the 2PB one).