Under normal circumstances, MIR shims have the following 5 passes applied:
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 the MirPhase 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 and AbortUnwindingCalls have soundness implications, and CriticalCallEdges 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?
Under normal circumstances, MIR shims have the following 5 passes applied:
AddMovesForPackedDropsRemoveNoopLandingPadsSimplifyCfg(a trivial cleanup pass)CriticalCallEdgesAbortUnwindingCallsHowever, 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_passessilently returned without doing anything if theMirPhasewas 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
AddMovesForPackedDropsandAbortUnwindingCallshave soundness implications, andCriticalCallEdgesis 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?