In-Depth Look at Open Drops, Enum Handling, Cleanup Paths, and Const-Eval Interaction in Drop Elaboration

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 whole is the same as the initializedness of its fields. Therefore, once we generate a drop flag for the target of that drop, it's safe to call the drop glue for that target. ### `Open` drops `Open` drops are the most complex, since we need to break down a single `Drop` terminator into several different ones, one for each field of the target whose type has drop glue (`Ty::needs_drop`). We cannot call the drop glue for the target itself because that requires all fields of the target to be initialized. Remember, variables whose type has a custom `Drop` impl do not allow `Open` drops because their fields cannot be moved from. This is accomplished by recursively categorizing each field as `Dead`, `Static`, `Conditional` or `Open`. Fields whose type does not have drop glue are automatically `Dead` and need not be considered during the recursion. When we reach a field whose kind is not `Open`, we handle it as we did above. If the field is also `Open`, the recursion continues. It's worth noting how we handle `Open` drops of enums. Inside drop elaboration, each variant of the enum is treated like a field, with the invariant that only one of those "variant fields" can be initialized at any given time. In the general case, we do not know which variant is the active one, so we will have to call the drop glue for the enum (which checks the discriminant) or check the discriminant ourselves as part of an elaborated `Open` drop. However, in certain cases (within a `match` arm, for example) we do know which variant of an enum is active. This information is encoded in the `MaybeInitializedPlaces` and `MaybeUninitializedPlaces` dataflow analyses by marking all places corresponding to inactive variants as uninitialized. ### Cleanup paths TODO: Discuss drop elaboration and unwinding. ## Aside: drop elaboration and const-eval In Rust, functions that are eligible for evaluation at compile-time must be marked explicitly using the `const` keyword. This includes implementations of the `Drop` trait, which may or may not be `const`. Code that is eligible for compile-time evaluation may only call `const` functions, so any calls to non-const `Drop` implementations in such code must be forbidden. A call to a `Drop` impl is encoded as a `Drop` terminator in the MIR. However, as we discussed above, a `Drop` terminator in newly built MIR does not necessarily result in a call to `Drop::drop`. The drop target may be uninitialized at that point. This means that checking for non-const `Drop`s on the newly built MIR can result in spurious errors. Instead, we wait until after drop elaboration runs, which eliminates `Dead` drops (ones where the target is known to be uninitialized) to run these checks.

This section delves into the intricacies of 'Open' drops, which handle partially initialized variables by breaking down the drop into individual fields that need dropping. It explains the recursive categorization of fields into `Dead`, `Static`, `Conditional`, or `Open` and how enums are treated during drop elaboration, particularly how inactive variants are handled via dataflow analysis. A brief mention is made of cleanup paths in relation to drop elaboration and unwinding. Finally, the section discusses the interaction between drop elaboration and const-eval, noting that the compiler must wait until after drop elaboration to check for non-const `Drop` implementations to avoid spurious errors due to uninitialized drop targets.