Binding subpattern with @ allows for illegal mutation #14587
Assignees
Milestone
Comments
|
That sounds quite bad, nominating. |
|
P-backcompat-lang, 1.0. |
|
cc me |
|
Ah, I think I know why this happens. Fascinating. It's no doubt because the matched expression is an rvalue. I think we'll have to upgrade how rvalues are handled in borrowck to fix this. |
|
cc #12534 |
|
Basically the problem is that we treat rvalues as though they are only ever once -- but with a devious match expression like this one you can arrange to consume them / borrow them multiple times. I think we ought to modify the memcategorization to store the expr-id of the rvalue and not just the temporary scope -- the borrow checker can then treat rvalues just as it treats lvalues. Basically we want to have the borrow checker reason about the temporary that will be created. |
pcwalton
added a commit
to pcwalton/rust
that referenced
this issue
Aug 1, 2014
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]
bors
added a commit
that referenced
this issue
Aug 1, 2014
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
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Jun 5, 2023
fix: Bring back LRU limit for macro_expand query Should fix the memory increase
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This code compiles even though it should be rejected since writing to z invalidates the a variable.
The text was updated successfully, but these errors were encountered: