Pass the right ParamEnv to might_permit_raw_init_strict
#128720
Merged
Conversation
This file contains 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
|
rustbot has assigned @petrochenkov. Use |
rustbot
added
the
S-waiting-on-review
|
Some changes occurred in src/tools/clippy cc @rust-lang/clippy |
rustbot
added
the
T-compiler
|
@bors r+ rollup |
bors
added
S-waiting-on-bors
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Aug 6, 2024
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#128369 (rustc_lint: make `let-underscore-lock` translatable) - rust-lang#128377 (Fix ICE Caused by Incorrectly Delaying E0107) - rust-lang#128517 (Fallback to string formatting if source is not available for lint) - rust-lang#128685 (Remove the root Cargo.lock from the rust-src component) - rust-lang#128693 (rustdoc-search: account for numeric disambiguators on impls) - rust-lang#128720 (Pass the right `ParamEnv` to `might_permit_raw_init_strict`) - rust-lang#128736 (Fix rustdoc missing handling of remap-path-prefix option) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Aug 7, 2024
Rollup merge of rust-lang#128720 - y21:issue119620, r=compiler-errors Pass the right `ParamEnv` to `might_permit_raw_init_strict` Fixes rust-lang#119620 `might_permit_raw_init_strict` currently passes an empty `ParamEnv` to the `InterpCx`, instead of the actual `ParamEnv` that was passed in to `check_validity_requirement` at callsite. This leads to ICEs such as the linked issue where for `UnsafeCell<*mut T>` we initially get the layout with the right `ParamEnv` (which suceeds because it can prove that `T: Sized` and therefore `UnsafeCell<*mut T>` has a known layout) but then do the rest with an empty `ParamEnv` where `T: Sized` is not known to hold so getting the layout for `*mut T` later fails. This runs into an assertion in other layout code where it's making the (valid) assumption that, when we already have a layout for a struct (`UnsafeCell<*mut T>`), getting the layout of one of its fields (`*mut T`) should also succeed, which wasn't the case here due to using the wrong `ParamEnv`. So, this PR changes it to just use the same `ParamEnv` all the way throughout.
bors
added a commit
to rust-lang/rust-clippy
that referenced
this pull request
Aug 8, 2024
Rustup r? `@ghost` changelog: ICE fix [`uninit_vec`] through rust-lang/rust#128720
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Fixes #119620
might_permit_raw_init_strictcurrently passes an emptyParamEnvto theInterpCx, instead of the actualParamEnvthat was passed in tocheck_validity_requirementat callsite.This leads to ICEs such as the linked issue where for
UnsafeCell<*mut T>we initially get the layout with the rightParamEnv(which suceeds because it can prove thatT: Sizedand thereforeUnsafeCell<*mut T>has a known layout) but then do the rest with an emptyParamEnvwhereT: Sizedis not known to hold so getting the layout for*mut Tlater fails.This runs into an assertion in other layout code where it's making the (valid) assumption that, when we already have a layout for a struct (
UnsafeCell<*mut T>), getting the layout of one of its fields (*mut T) should also succeed, which wasn't the case here due to using the wrongParamEnv.So, this PR changes it to just use the same
ParamEnvall the way throughout.