-
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
Which MIR passes should run on generator drop shims? #91576
Comments
I'm not sure why those passes aren't run, and I haven't done much on the code with drop shims. @Zoxc might know. @jonas-schievink also made some recent-ish changes in that code. |
The On the other hand, the omission of |
…anup, r=oli-obk Address some FIXMEs left over from rust-lang#91475 This shouldn't change behavior, only clarify what we're currently doing. I filed rust-lang#91576 to see if the treatment of generator drop shims is intentional. cc rust-lang#91475
…anup, r=oli-obk Address some FIXMEs left over from rust-lang#91475 This shouldn't change behavior, only clarify what we're currently doing. I filed rust-lang#91576 to see if the treatment of generator drop shims is intentional. cc rust-lang#91475
This issue also means that MIR validation doesn't run on generator drop shims, which makes me uneasy. Or has the validator been run somewhere earlier?
Which original MIR and where/how is that generated?
What would go wrong if this made the same |
Under normal circumstances, MIR shims have the following 5 passes applied:
AddMovesForPackedDrops
RemoveNoopLandingPads
SimplifyCfg
(a trivial cleanup pass)CriticalCallEdges
AbortUnwindingCalls
However, generator drop shims are created by cloning the MIR for the original generator (?), which means they start out in
MirPhase::GeneratorLowering
. Prior to #91475,run_passes
silently returned without doing anything if theMirPhase
was greater than or equal to the expected one, so the aforementioned MIR passes were never executed. That behavior was only relevant when building drop shims, so #91475 added an explicit check to preserve it.Was this intentional? Notably
AddMovesForPackedDrops
andAbortUnwindingCalls
have soundness implications, andCriticalCallEdges
is needed to work around some codegen issues, so it seems like they should always run. However, they might not be applicable to generators specifically.Perhaps @tmandry knows the answer, or knows someone who does?
The text was updated successfully, but these errors were encountered: