-
Notifications
You must be signed in to change notification settings - Fork 13.3k
MIR building optimizes away some place expressions around "_" patterns even with -Zmir-opt-level=0 #99180
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Labels
A-MIR
Area: Mid-level IR (MIR) - https://blog.rust-lang.org/2016/04/19/MIR.html
C-bug
Category: This is a bug.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
This doesn't even need the |
Yeah that's what I mentioned in the last paragraph about THIR unsafety checking. |
This got fixed by #102256. |
This required |
Also turns out the |
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Oct 27, 2023
…RalfJung Allow partially moved values in match This PR attempts to unify the behaviour between `let _ = PLACE`, `let _: TY = PLACE;` and `match PLACE { _ => {} }`. The logical conclusion is that the `match` version should not check for uninitialised places nor check that borrows are still live. The `match PLACE {}` case is handled by keeping a `FakeRead` in the unreachable fallback case to verify that `PLACE` has a legal value. Schematically, `match PLACE { arms }` in surface rust becomes in MIR: ```rust PlaceMention(PLACE) match PLACE { // Decision tree for the explicit arms arms, // An extra fallback arm _ => { FakeRead(ForMatchedPlace, PLACE); unreachable } } ``` `match *borrow { _ => {} }` continues to check that `*borrow` is live, but does not read the value. `match *borrow {}` both checks that `*borrow` is live, and fake-reads the value. Continuation of ~rust-lang#102256 ~rust-lang#104844 Fixes rust-lang#99180 rust-lang#53114
github-actions bot
pushed a commit
to rust-lang/miri
that referenced
this issue
Oct 28, 2023
Allow partially moved values in match This PR attempts to unify the behaviour between `let _ = PLACE`, `let _: TY = PLACE;` and `match PLACE { _ => {} }`. The logical conclusion is that the `match` version should not check for uninitialised places nor check that borrows are still live. The `match PLACE {}` case is handled by keeping a `FakeRead` in the unreachable fallback case to verify that `PLACE` has a legal value. Schematically, `match PLACE { arms }` in surface rust becomes in MIR: ```rust PlaceMention(PLACE) match PLACE { // Decision tree for the explicit arms arms, // An extra fallback arm _ => { FakeRead(ForMatchedPlace, PLACE); unreachable } } ``` `match *borrow { _ => {} }` continues to check that `*borrow` is live, but does not read the value. `match *borrow {}` both checks that `*borrow` is live, and fake-reads the value. Continuation of ~rust-lang/rust#102256 ~rust-lang/rust#104844 Fixes rust-lang/rust#99180 rust-lang/rust#53114
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Labels
A-MIR
Area: Mid-level IR (MIR) - https://blog.rust-lang.org/2016/04/19/MIR.html
C-bug
Category: This is a bug.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Consider the following code -- the comments say it all:
Here is the mir-opt-level=0 MIR for this:
Currently, MIR building "loses" the entire place expression somewhere, even though that place expression could cause UB. IMO that is a bug. Can we change MIR building to preserve the place expressions?
We could have a
EvalPlace
MIR statement that just computes a place expression and then does nothing with the result. (To be clear, there should be no place-to-value conversion, i.e., no actual load from the*ptr
place. But the place expression itself should be evaluated.) We do haveFakeRead
, which works on a place, but (a) its docs talk about "inspecting constants and discriminant values" so that is doing more than just evaluating the place expression, and (b) it is "disallowed after drop elaboration".Cc @rust-lang/wg-mir-opt in lieu of a "MIR building wg".
Also I think this is related to THIR unsafety checking; MIR unsafety checking does not even complain about some of these
*ptr
because they get erased before reaching MIR, but in THIR they would still be visible.Also related: #79735 rust-lang/unsafe-code-guidelines#261
The text was updated successfully, but these errors were encountered: