-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suppress ICE when validators disagree on LiveDrop
s in presence of &mut
#65485
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