# Drop Check We generally require the type of locals to be well-formed whenever the local is used. This includes proving the where-bounds of the local and also requires all regions used by it to be live. The only exception to this is when implicitly dropping values when they go out of scope. This does not necessarily require the value to be live: ```rust fn main() { let x = vec![]; { let y = String::from("I am temporary"); x.push(&y); } // `x` goes out of scope here, after the reference to `y` // is invalidated. This means that while dropping `x` its type // is not well-formed as it contain regions which are not live. } ``` This is only sound if dropping the value does not try to access any dead region. We check this by requiring the type of the value to be drop-live. The requirements for which are computed in `fn dropck_outlives`. The rest of this section uses the following type definition for a type which requires its region parameter to be live: ```rust struct PrintOnDrop<'a>(&'a str); impl<'a> Drop for PrintOnDrop<'_> { fn drop(&mut self) { println!("{}", self.0); } } ``` ## How values are dropped At its core, a value of type `T` is dropped by executing its "drop glue". Drop glue is compiler generated and first calls `::drop` and then recursively calls the drop glue of any recursively owned values. - If `T` has an explicit `Drop` impl, call `::drop`. - Regardless of whether `T` implements `Drop`, recurse into all values *owned* by `T`: - references, raw pointers, function pointers, function items, trait objects[^traitobj], and scalars do not own anything. - tuples, slices, and arrays consider their elements to be owned. For arrays of length zero we do not own any value of the element type. - all fields (of all variants) of ADTs are considered owned. We consider all variants for enums. The exception here is `ManuallyDrop` which is not considered to own `U`. `PhantomData` also does not own anything. closures and generators own their captured upvars. Whether a type has drop glue is returned by [`fn Ty::needs_drop`](https://github.com/rust-lang/rust/blob/320b412f9c55bf480d26276ff0ab480e4ecb29c0/compiler/rustc_middle/src/ty/util.rs#L1086-L1108). ### Partially dropping a local For types which do not implement `Drop` themselves, we can also partially move parts of the value before dropping the rest. In this case only the drop glue for the not-yet moved values is called, e.g. ```rust fn main() { let mut x = (PrintOnDrop("third"), PrintOnDrop("first")); drop(x.1); println!("second") } ``` During MIR building we assume that a local may get dropped whenever it goes out of scope *as long as its type needs drop*. Computing the exact drop glue for a variable happens **after** borrowck in the `ElaborateDrops` pass. This means that even if some part of the local have been dropped previously, dropck still requires this value to be live. This is the case even if we completely moved a local. ```rust fn main() { let mut x; { let temp = String::from("I am temporary"); x = PrintOnDrop(&temp); drop(x); } } //~ ERROR `temp` does not live long enough. ``` It should be possible to add some amount of drop elaboration before borrowck, allowing this example to compile. There is an unstable feature to move drop elaboration before const checking: [#73255](https://github.com/rust-lang/rust/issues/73255). Such a feature gate does not exist for doing some drop elaboration before borrowck, although there's a [relevant MCP](https://github.com/rust-lang/compiler-team/issues/558). [^traitobj]: you can consider trait objects to have a builtin `Drop` implementation which directly uses the `drop_in_place` provided by the vtable. This `Drop` implementation requires all its generic parameters to be live. ### `dropck_outlives` There are two distinct "liveness" computations that we perform: * a value `v` is *use-live* at location `L` if it may be "used" later; a *use* here is basically anything that is not a *drop* * a value `v` is *drop-live* at location `L` if it maybe dropped later When things are *use-live*, their entire type must be valid at `L`. When they are *drop-live*, all regions that are required by dropck must be valid at `L`. The values dropped in the MIR are *places*. The constraints computed by `dropck_outlives` for a type closely match the generated drop glue for that type. Unlike drop glue, `dropck_outlives` cares about the types of owned values, not the values itself. For a value of type `T` - if `T` has an explicit `Drop`, require all generic arguments to be live, unless they are marked with `#[may_dangle]` in which case they are fully ignored - regardless of whether `T` has an explicit `Drop`, recurse into all types *owned* by `T` - references, raw pointers, function pointers, function items, trait objects[^traitobj], and scalars do not own anything. - tuples, slices and arrays consider their element type to be owned. **For arrays we currently do not check whether their length is zero**. - all fields (of all variants) of ADTs are considered owned. The exception here is `ManuallyDrop` which is not considered to own `U`. **We consider `PhantomData` to own `U`**. - closures and generators own their captured upvars. The sections marked in bold are cases where `dropck_outlives` considers types to be owned which are ignored by `Ty::needs_drop`. We only rely on `dropck_outlives` if `Ty::needs_drop` for the containing local returned `true`.This means liveness requirements can change depending on whether a type is contained in a larger local. **This is inconsistent, and should be fixed: an example [for arrays](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=8b5f5f005a03971b22edb1c20c5e6cbe) and [for `PhantomData`](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=44c6e2b1fae826329fd54c347603b6c8).**[^core] One possible way these inconsistencies can be fixed is by MIR building to be more pessimistic, probably by making `Ty::needs_drop` weaker, or alternatively, changing `dropck_outlives` to be more precise, requiring fewer regions to be live. [^core]: This is the core assumption of [#110288](https://github.com/rust-lang/rust/issues/110288) and [RFC 3417](https://github.com/rust-lang/rfcs/pull/3417).