You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fix spurious error when a Drop local has an assignment in a loop
`DropAndReplace` terminators are special - unlike all other terminators,
they perform two distinct actions (a drop and a store) to the same
`Place`. This complicates various analysis passes that we do,
which expect at most one of 'Drop'/'Def'/'Use' for a local at
a given MIR location.
Previously, we categorized a `DropAndReplace` terminator's `Local`
access as `MutatingUseContext::Drop`. As a result, livness computation
would not consider the `DropAndReplace` as a store ('Def') of a local.
The "use live" set would end up being too large (a use would
be seen to extend back to an earlier store, rather than the closure
`DropAndReplace`).
We now explicitly propagate information about `DropAndReplace`
terminators via new enum variants `MutatingUseContext:DropAndReplace`
and `DefUse::DropAndReplace`. We use this information in liveness
computation to record *both* a Drop and a Def. This prevents creating
an extra-large "use live" set, while ensuring that te local is still
considered "drop live" at the required locations.
0 commit comments