Allow unnormalized types in drop elaboration #148719
Merged
Conversation
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
Collaborator
| Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt |
rustbot added S-waiting-on-review Collaborator
| r? @SparrowLii rustbot has assigned @SparrowLii. Use |
Collaborator
|
Member Author
| r? compiler |
Member
| Seems fine, but I'm not too sure about the impact of this change @rustbot reroll |
Member Author
| Maybe cc @matthewjasper (the error was introduced in #136539). |
Member
| I'll give a few days for a response, but I agree with your reasoning in the PR description. |
Contributor
| I think this change is fine, borrow checking should catch the actual errors here. |
Member
| @bors r+ |
Collaborator
bors added S-waiting-on-bors 
bors added a commit that referenced this pull request Nov 21, 2025
Rollup of 7 pull requests Successful merges: - #146978 (Emit error when using path-segment keyword as cfg pred) - #148719 (Allow unnormalized types in drop elaboration) - #148795 (add `rust.rustflags` and per target `rustflags` options to `bootstrap.toml`) - #149028 ([rustdoc] Remove `UrlFragment::render` method to unify `clean::types::links` and `anchor`) - #149043 ( rustdoc-json: add rlib path to ExternalCrate to enable robust crate resolution) - #149098 (Fix error message for calling a non-tuple struct) - #149151 (Add test for importing path-segment keyword) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer added a commit that referenced this pull request Nov 22, 2025
Rollup merge of #148719 - Nadrieril:poly-drop-glue, r=saethlin Allow unnormalized types in drop elaboration I work on a [rustc driver](https://github.com/AeneasVerif/charon) that aims to extract the full polymorphic MIR of a crate. Currently the one thing I can't get is drop glue because it fails on unnormalizable types like the fields of `Cow` or `NonZero`. This PR removes the one check for unnormalized types in drop elaboration. It's a `span_delay_bug` so only there to help catch mistakes. I think that's fine to remove? If something downstream relies on types being normalized the right approach is for MIR validation to check for normalized types, not that one random check.
This was referenced Nov 25, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
7 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.
I work on a rustc driver that aims to extract the full polymorphic MIR of a crate. Currently the one thing I can't get is drop glue because it fails on unnormalizable types like the fields of
CoworNonZero.This PR removes the one check for unnormalized types in drop elaboration. It's a
span_delay_bugso only there to help catch mistakes. I think that's fine to remove? If something downstream relies on types being normalized the right approach is for MIR validation to check for normalized types, not that one random check.