-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Suppress ICE when validators disagree on LiveDrop
s in presence of &mut
#65485
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
Suppress ICE when validators disagree on LiveDrop
s in presence of &mut
#65485
Conversation
LiveDrop
s in presence of &mut
LiveDrop
s in presence of &mut
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. |
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. |
That's... a perplexing example. I'd expect |
@bors r+ |
📌 Commit af691de has been approved by |
…match-ugliness, r=eddyb Suppress ICE when validators disagree on `LiveDrop`s in presence of `&mut` Resolves rust-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
…match-ugliness, r=eddyb Suppress ICE when validators disagree on `LiveDrop`s in presence of `&mut` Resolves rust-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
…match-ugliness, r=eddyb Suppress ICE when validators disagree on `LiveDrop`s in presence of `&mut` Resolves rust-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
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
Resolves #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 ofLiveDrop
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.This code is not UB AFAIK (it passes MIRI at least). The current validator does not emit a
LiveDrop
error forx
upon exit from the initializer.x
is not actually dropped, so I think this is correct? A proper fix for this would require a newMaybeInitializedLocals
dataflow analysis or maybe a relaxation of the existingIndirectlyMutableLocals
one.r? @RalfJung