librustc: Forbid pattern bindings after @s, for memory safety.
#16053
Conversation
|
Rebased. |
|
@nikomatsakis I'm happy to punt to @pnkfelix if you'd like. |
|
(reviewing now) |
|
This seems like a pretty severe weakening of |
|
@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 I guess as long as the hypothetical re-implementor of |
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 rust-lang#14587.
[breaking-change]
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
Note that due to PR rust-lang#16053, we only actually deal with `a @ Var(_)` here, (as opposed to a hypothetical `a @ Var(ref b)`, which cannot currenty arise, and maybe will never be supported for non-copy data).
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!(),
};
}
} |
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). |
|
Are there any plans to implement a correct handling of these bindings for |
Initial implementation of `#![feature(bindings_after_at)]` Following up on #16053, under the gate `#![feature(bindings_after_at)]`, `x @ Some(y)` is allowed subject to restrictions necessary for soundness. The implementation and test suite should be fairly complete now. One aspect that is not covered is the interaction with nested `#![feature(or_patterns)]`. This is not possible to test at the moment in a good way because that feature has not progressed sufficiently and has fatal errors in MIR building. We should make sure to add such tests before we stabilize both features (but shipping one of them is fine). r? @pnkfelix cc @nikomatsakis @matthewjasper @pcwalton cc #65490
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 andlibraries.
This breaks code like:
Change this code to use nested
matchorletexpressions. Forexample:
Closes #14587.
[breaking-change]
May need discussion at the meeting, but r? @nikomatsakis anyway