librustc: Forbid pattern bindings after @s, for memory safety.

[pcwalton]

This is an alternative to upgrading the way rvalues are handled in the
borrow check. Making rvalues handled more like lvalues in the borrow
check caused numerous problems related to double mutable borrows and
rvalue scopes. Rather than come up with more borrow check rules to try
to solve these problems, I decided to just forbid pattern bindings after
@. This affected fewer than 10 lines of code in the compiler and
libraries.

This breaks code like:

match x {
    y @ z => { ... }
}

match a {
    b @ Some(c) => { ... }
}

Change this code to use nested match or let expressions. For
example:

match x {
    y => {
        let z = y;
        ...
    }
}

match a {
    Some(c) => {
        let b = Some(c);
        ...
    }
}

Closes #14587.

[breaking-change]

May need discussion at the meeting, but r? @nikomatsakis anyway

[pcwalton]

Rebased.

[pcwalton]

@nikomatsakis I'm happy to punt to @pnkfelix if you'd like.

[pnkfelix]

(reviewing now)

[pnkfelix]

This seems like a pretty severe weakening of @-patterns; so I just want to point out to on-lookers that the decision at the weekly meeting was to put this change in for now, with the expectation/hope that we'll fix things and re-enable bindings in the rhs of @ at some later point.

[pnkfelix]

@nikomatsakis do you think we should be deleting the tests as the current PR does, or mark them as ignored? (I'm assuming that the ignore flag should suffice, its not like those tests will stop parsing due to this change...)

I guess as long as the hypothetical re-implementor of @-pattern with rhs-binding support does their due-diligence, they should know to re-enable the tests.

[chpio]

This breaks code like:

match x {
   y @ z => { ... }
}

match a {
    b @ Some(c) => { ... }
}

Change this code to use nested match or let expressions. For
example:

match x {
   y => {
       let z = y;
       ...
   }
}

match a {
   Some(c) => {
       let b = Some(c);
       ...
   }
}

ok, but how to fix this:

match a {
  Some(b @ &MyEnum::Foo(ref c)) => {
  }
}

Foo can only take values, no refs. So this wouldn't work:

match a {
  Some(&MyEnum::Foo(ref c)) => {
    let b = MyEnum::Foo(c);
    // mismatched types
    // expected type `Bar`
    //    found type `&Bar`
  }
}

i can think only of this workaround:

match a {
  Some(b @ MyEnum::Foo(..)) => {
    let c = match b {
      &MyEnum::Foo(ref c) => c,
      _ => unreachable!(),
    };
  }
}

[nikomatsakis]

i can think only of this workaround:

Yeah, that seems about right. It'd be nice to fix this in a better way (internal refactorings to use MIR ought to help here).

[ozkriff]

Are there any plans to implement a correct handling of these bindings for Copy types?