Use try_normalize_erasing_regions in MIR validation#153327
Closed
DukeDeSouth wants to merge 2 commits intorust-lang:mainfrom
Closed
Use try_normalize_erasing_regions in MIR validation#153327DukeDeSouth wants to merge 2 commits intorust-lang:mainfrom
DukeDeSouth wants to merge 2 commits intorust-lang:mainfrom
Conversation
MIR validation calls `normalize_erasing_regions` to check field types and transmute sizing. This panics when the type involves opaque aliases wrapping error types from incomplete trait impls. Replace the four call sites with `try_normalize_erasing_regions`, falling back to the unnormalized type (or skipping the check) when normalization fails. This matches the pattern used in `elaborate_drop.rs` and `needs_drop.rs`. Fixes rust-lang#140303 Made-with: Cursor
Collaborator
|
Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt |
rustbot
added
S-waiting-on-review
Collaborator
|
r? @mati865 rustbot has assigned @mati865. Use Why was this reviewer chosen?The reviewer was selected based on:
|
Collaborator
|
This comment has been minimized.
This comment has been minimized.
Made-with: Cursor
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
Member
|
Is this truly the right fix? Basically that means we have to make all MIR consumers robust against such non-normalizable types. There's a good reason for MIR validation to be strict here. We definitely shouldn't relax it without someone confirming/auditing MIR passes to ensure they can work with the new MIR this PR intends to declare valid. |
Contributor
|
This github account's first PR was to openclaw. Then they opened 8 or so PRs to a similar number of entirely unrelated repos in one day. Hi. This is the moderation team of the Rust project. Your interaction with the Rust project has been identified as spammy, not constructive, or malicious. This goes against our Code of Conduct. We are thus banning you as per our policy. You can contact the moderation team to discuss and possibly reconsider your ban. |
rustbot
removed
the
S-waiting-on-review
Contributor
|
Also the user was previously warned about vibe coded PRs: #152319 (comment) |
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 free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
6 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.
MIR validation calls normalize_erasing_regions in four places to check
field types on aggregates and sizing on transmutes. When the type
involves opaque aliases wrapping error types (e.g. from an incomplete
trait impl), normalization fails and the compiler panics.
Switched these four call sites to try_normalize_erasing_regions, falling
back to the unnormalized type or skipping the check. Same pattern used
in elaborate_drop and needs_drop elsewhere in the compiler.
Moved the crash test to a proper UI regression test.
Fixes #140303.
Made with Cursor