Uh oh!
There was an error while loading. Please reload this page.
Suppress ICE when validators disagree on LiveDrops in presence of &mut - #65485
Merged
bors merged 3 commits intoOct 19, 2019
Merged
Conversation
LiveDrops in presence of &mutLiveDrops in presence of &mutMember
I'm afraid I am mostly unfamiliar with const qualification after all the recent changes. I didn't follow the "new validator" in any detail (oh man the name is confusing, I thought you were talking about this) -- I just don't have the time to do that next to all the UCG and Miri things, sorry. |
RalfJung
commented
Oct 17, 2019
Member
That's just an artifact of what Miri happens to check right now -- this is the kind of code where really we have no idea if we have to make it UB, want to make it UB, or whatever. |
eddyb
commented
Oct 18, 2019
Contributor
That's... a perplexing example. I'd expect |
eddyb
approved these changes
Oct 18, 2019
eddyb
commented
Oct 18, 2019
Contributor
@bors r+ |
bors
commented
Oct 18, 2019
Collaborator
📌 Commit af691de has been approved by |
Centril added a commit
to Centril/rust
that referenced
this pull request
Oct 19, 2019
…match-ugliness, r=eddyb Suppress ICE when validators disagree on `LiveDrop`s in presence of `&mut` Resolvesrust-lang#65394. This hack disables the validator mismatch ICE in cases where a `MutBorrow` error has been emitted by both validators, but they don't agree on the number of `LiveDrop` errors. The new validator is more conservative about whether a value is moved from in the presence of mutable borrows. For example, the new validator will emit a `LiveDrop` error on the following code. ```rust const _: Vec<i32> = { let mut x = Vec::new(); let px = &mut x as *mut _; let y = x; unsafe { ptr::write(px, Vec::new()); } y }; ``` This code is not UB AFAIK (it passes MIRI at least). The current validator does not emit a `LiveDrop` error for `x` upon exit from the initializer. `x` is not actually dropped, so I think this is correct? A proper fix for this would require a new `MaybeInitializedLocals` dataflow analysis or maybe a relaxation of the existing `IndirectlyMutableLocals` one. r? @RalfJung
Centril added a commit
to Centril/rust
that referenced
this pull request
Oct 19, 2019
…match-ugliness, r=eddyb Suppress ICE when validators disagree on `LiveDrop`s in presence of `&mut` Resolvesrust-lang#65394. This hack disables the validator mismatch ICE in cases where a `MutBorrow` error has been emitted by both validators, but they don't agree on the number of `LiveDrop` errors. The new validator is more conservative about whether a value is moved from in the presence of mutable borrows. For example, the new validator will emit a `LiveDrop` error on the following code. ```rust const _: Vec<i32> = { let mut x = Vec::new(); let px = &mut x as *mut _; let y = x; unsafe { ptr::write(px, Vec::new()); } y }; ``` This code is not UB AFAIK (it passes MIRI at least). The current validator does not emit a `LiveDrop` error for `x` upon exit from the initializer. `x` is not actually dropped, so I think this is correct? A proper fix for this would require a new `MaybeInitializedLocals` dataflow analysis or maybe a relaxation of the existing `IndirectlyMutableLocals` one. r? @RalfJung
Centril added a commit
to Centril/rust
that referenced
this pull request
Oct 19, 2019
…match-ugliness, r=eddyb Suppress ICE when validators disagree on `LiveDrop`s in presence of `&mut` Resolvesrust-lang#65394. This hack disables the validator mismatch ICE in cases where a `MutBorrow` error has been emitted by both validators, but they don't agree on the number of `LiveDrop` errors. The new validator is more conservative about whether a value is moved from in the presence of mutable borrows. For example, the new validator will emit a `LiveDrop` error on the following code. ```rust const _: Vec<i32> = { let mut x = Vec::new(); let px = &mut x as *mut _; let y = x; unsafe { ptr::write(px, Vec::new()); } y }; ``` This code is not UB AFAIK (it passes MIRI at least). The current validator does not emit a `LiveDrop` error for `x` upon exit from the initializer. `x` is not actually dropped, so I think this is correct? A proper fix for this would require a new `MaybeInitializedLocals` dataflow analysis or maybe a relaxation of the existing `IndirectlyMutableLocals` one. r? @RalfJung
bors added a commit
that referenced
this pull request
Oct 19, 2019
Rollup of 6 pull requests Successful merges: - #65174 (Fix zero-size uninitialized boxes) - #65252 (expand: Simplify expansion of derives) - #65485 (Suppress ICE when validators disagree on `LiveDrop`s in presence of `&mut`) - #65542 (Refer to "associated functions" instead of "static methods") - #65545 (More symbol cleanups) - #65576 (Don't add `argc` and `argv` arguments to `main` on WASI.) Failed merges: r? @ghost
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Resolves#65394.
This hack disables the validator mismatch ICE in cases where a
MutBorrowerror has been emitted by both validators, but they don't agree on the number ofLiveDroperrors.The new validator is more conservative about whether a value is moved from in the presence of mutable borrows. For example, the new validator will emit a
LiveDroperror on the following code.This code is not UB AFAIK (it passes MIRI at least). The current validator does not emit a
LiveDroperror forxupon exit from the initializer.xis not actually dropped, so I think this is correct? A proper fix for this would require a newMaybeInitializedLocalsdataflow analysis or maybe a relaxation of the existingIndirectlyMutableLocalsone.r? @RalfJung