-
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
Normalize opaque alias type #116378
Normalize opaque alias type #116378
Conversation
446a2bb
to
7d17d04
Compare
added fix for #116265 in second commit |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there are two fixes here, for the subtyping issues, we can run the Subtyper
pass in run_runtime_lowering_passes
after &reveal_all::RevealAdd
, this should normalize all opaques.
For the opaque types issue I would expect a normalize_erasing_regions
call to happen earlier, so that parent_ty
is never an unnormalized opaque if we're in Reveal::All
I'm in no favor of these solutions but there is something weird going on with But removing |
Part of the issue is that a field projection can result in an opaque type again, and after stripping the opaque type projection (which would turn it into the hidden type), we end up failing follow up projections. Your fixes resolve this at the sites that cause ICEs. I've been trying to figure out if we can instead make projecions reveal immediately and thus not require users of the I don't remember where I stopped on Friday while investigating this, but after the long German weekend (tomorrow) I'll post my findings here. A quick fix that I'd prefer would be to stop stripping OpaqueTy projections and allow them again in the mir visitor. |
I wonder if its best to revert #115025 for now (before the nightly release in a couple hours) since we are already getting "my crate failed to build" reports from nightly users :/ |
Going to open a new PR for these fixes, we are already departed from original goal of this PR. |
Well, could also revert both 😅 |
Closing this in favor of #116415 |
Move subtyper below reveal_all and change reveal_all In previous attempt rust-lang#116378 we tried to handle `Opaque` in few different places, but this isn't necessary, after moving subtyper below reveal_all and calling `super_place` on reveal_all, issues cease to exist. r? `@oli-obk` Fixes rust-lang#116332 Fixes rust-lang#116265 Fixes rust-lang#116383 Fixes rust-lang#116333
Move subtyper below reveal_all and change reveal_all In previous attempt rust-lang#116378 we tried to handle `Opaque` in few different places, but this isn't necessary, after moving subtyper below reveal_all and calling `super_place` on reveal_all, issues cease to exist. r? ``@oli-obk`` Fixes rust-lang#116332 Fixes rust-lang#116265 Fixes rust-lang#116383 Fixes rust-lang#116333
Rollup merge of rust-lang#116415 - ouz-a:move_subtyper, r=oli-obk Move subtyper below reveal_all and change reveal_all In previous attempt rust-lang#116378 we tried to handle `Opaque` in few different places, but this isn't necessary, after moving subtyper below reveal_all and calling `super_place` on reveal_all, issues cease to exist. r? ``@oli-obk`` Fixes rust-lang#116332 Fixes rust-lang#116265 Fixes rust-lang#116383 Fixes rust-lang#116333
In cases like #116332, we might end up with
Alias(Opaque)
, which causes match to ICE, this fixes that by normalizing opaque value we get.Fixes #116332
Fixes #116265
Fixes #116383
r? @oli-obk