Drop Elaboration Details and Implementation in `rustc`

## Drop elaboration One valid model for these rules is to keep a boolean flag (a "drop flag") for every structural path that is used at any point in the function. This flag is set when its path is initialized and is cleared when the path is moved from. When a `Drop` occurs, we check the flags for every obligation associated with the target of the `Drop` and call the associated `Drop` impl for those that are still applicable. This process—transforming the newly built MIR with its imprecise `Drop` and `DropAndReplace` terminators into one with drop flags—is known as drop elaboration. When a MIR statement causes a variable to become initialized (or uninitialized), drop elaboration inserts code that sets (or clears) the drop flag for that variable. It wraps `Drop` terminators in conditionals that check the newly inserted drop flags. Drop elaboration also splits `DropAndReplace` terminators into a `Drop` of the target and a write of the newly dropped place. This is somewhat unrelated to what we've discussed above. Once this is complete, `Drop` terminators in the MIR correspond to a call to the "drop glue" or "drop shim" for the type of the dropped place. The drop glue for a type calls the `Drop` impl for that type (if one exists), and then recursively calls the drop glue for all fields of that type. ## Drop elaboration in `rustc` The approach described above is more expensive than necessary. One can imagine a few optimizations: - Only paths that are the target of a `Drop` (or have the target as a prefix) need drop flags. - Some variables are known to be initialized (or uninitialized) when they are dropped. These do not need drop flags. - If a set of paths are only dropped or moved from via a shared prefix, those paths can share a single drop flag. A subset of these are implemented in `rustc`. In the compiler, drop elaboration is split across several modules. The pass itself is defined [here][drops-transform], but the [main logic][drops] is defined elsewhere since it is also used to build [drop shims][drops-shim]. Drop elaboration designates each `Drop` in the newly built MIR as one of four kinds: - `Static`, the target is always initialized. - `Dead`, the target is always **un**initialized. - `Conditional`, the target is either wholly initialized or wholly uninitialized. It is not partly initialized. - `Open`, the target may be partly initialized. For this, it uses a pair of dataflow analyses, `MaybeInitializedPlaces` and `MaybeUninitializedPlaces`. If a place is in one but not the other, then the initializedness of the target is known at compile-time (`Dead` or `Static`). In this case, drop elaboration does not add a flag for the target. It simply removes (`Dead`) or preserves (`Static`) the `Drop` terminator. For `Conditional` drops, we know that the initializedness of the variable as a

This section elaborates on the drop elaboration process, explaining that drop flags track initialization. After drop elaboration, `Drop` terminators correspond to calls to drop glue, which handles the `Drop` implementation and recursively drops fields. The section then outlines optimizations to the basic approach, such as focusing drop flags on relevant paths, identifying statically known initialization states, and sharing drop flags for paths with a shared prefix. It describes how `rustc` implements drop elaboration across modules, classifying drops as `Static`, `Dead`, `Conditional`, or `Open` using dataflow analyses to determine initialization states.