https://github.com/rust-lang/types-team/issues/92

## What do I mean with dropck

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 the implicitly dropping values when they go out of scope. This does not necessarily require the value to be live:

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. The code responsible for this is `dropck_outlives`.

The rest of this document uses the following type definition for a type which requires its region parameter to be live:

struct PrintOnDrop<'a>(&'a str);
impl<'a> Drop for PrintOnDrop<'_> {
    fn drop(&mut self) {
        println!("{}", self.0);
    }
}

## How values are dropped

I mostly got the terminology and implementation details here from looking at the source. Please tell me if something feels off.

At its core, a value of type `T` is dropped by executing its "drop glue". Drop glue is compiler generated and first calls `<T as Drop>::drop` and then recursively calls the drop glue of any recursively owned values.

- If `T` has an explicit `Drop` impl, call `<T as Drop>::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<U>` which is not considered to own `U`. `PhantomData<U>` 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.

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.

fn main() {
    let mut x;
    {
        let temp = String::from("I am temporary");
        x = PrintOnDrop(&temp);
        drop(x);
    }
} //~ ERROR `temp` does not live long enough.

I think that 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). As far as I know such a feature gate does not exist for doing some drop elaboration before borrowck.

[^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. :shrug:

### `dropck_outlives`

During borrowck, we require a local to be valid for drop [at all locations before it is dropped](https://github.com/rust-lang/rust/blob/320b412f9c55bf480d26276ff0ab480e4ecb29c0/compiler/rustc_borrowck/src/type_check/liveness/trace.rs#L140-L162)[^livefacts] by adding the region constraints returned by [`dropck_outlives`](https://github.com/rust-lang/rust/blob/320b412f9c55bf480d26276ff0ab480e4ecb29c0/compiler/rustc_trait_selection/src/traits/query/dropck_outlives.rs#L80). For locals whose type does not need drop, i.e. `Ty::needs_drop` returned false, we do not emit drop statements during mir building, so these locals are never required to be valid wrt to drop.

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<U>` which is not considered to own `U`. **We consider `PhantomData<U>` 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]

I believe the only ways 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.

## Fixing the `[T; 0]` inconsistency ([#110288])

I propose to change `dropck_outlives` to not add outlives requirements for the element type of zero length arrays. Summarizing the discussion in that issue ([full summary](https://github.com/rust-lang/rust/issues/110288#issuecomment-1517872777)):
- We already specialcase arrays of length zero in quite a few other places, e.g. for `[T; 0]: Default` and also inside of the compiler itself.
- It feels sensible to not require the elements of zero length arrays to be live, people do not rely on the current `dropck_outlives` behavior. Making rustc more precise is generally preferable over making it "weaker".
- Changing `needs_drop` to be more pessimistic causes actual breakage found via crater.

## Fixing the `PhantomData<U>` inconsistency ([RFC 3417])

I propose to change `dropck_outlives` to not add outlives requirements for `U`. I still have to update the RFC, the main motivation is that `PhantomData` is `Copy`, returning `true` in `needs_drop` would also be inconsistent.

We have the issue that `PhantomData` is currently used together with `#[may_dangle]` to specify the exact `dropck_outlives` requirements.

`#[may_dangle]` *unsafely states* "this parameter *is not accessed* directly in the `Drop` implementation". Parameters with `#[may_dangle]` can still be required to be live by recursively owned types. This is incredibly subtle if the `Drop` implementation manually drops values of the parameter type.

For this to be sound, the parameter has to be considered live because it is recursively owned. This is often not the case when manually dropping values. We therefore currently add a `PhantomData` field owning the parameter to the type. This is subtle and easy to miss and we have already gotten this wrong multiple times: [#76367](https://github.com/rust-lang/rust/issues/76367) and [#99408](https://github.com/rust-lang/rust/issues/99408).

[RFC 3417] proposes to change may dangle to stop relying on recursive ownership by explicitly stating whether a parameter is completely unused or only dropped. I propose the syntax `#[may_dangle(must_not_use)]` and `#[may_dangle(can_drop)]` for this. We can then use a recursive ownership check to warn against unnecessarily *strong* `#[may_dangle]` attributes on `Drop` impls.

## The bright future

We can add assertions that `!dropck_outlives.is_empty()` implies `Ty::needs_drop`. `dropck_outlives` and `Ty::needs_drop` agree on the definitation of recursive ownership.

For a given type `T`, we have the following ownership rules:
- 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<U>` which is not considered to own `U`. `PhantomData<U>` does not own anything.
- closures and generators own their captured upvars.

Drop glue is generated as follows:
- if `T` has an explicit `Drop` impl, call `<T as Drop>::drop`[^traitobj].
- regardless of whether `T` has a `Drop` impl, recusively drop all values owned by `T`

The outlives requirements are computed as follows:
- if `T` has an explicit `Drop` impl, require all parameters to be live unless they are marked with `#[may_dangle]`:
- `#[may_dangle]` on lifetime parameters and `#[may_dangle(must_not_use)]` on type parameters cause us to fully ignore the parameter
- `#[may_dangle(may_drop)]` recurses into the type parameter as if it were recursively owned
- regardless of whether `T` has a `Drop` impl, recursively add the outlives requirements for types owned by `T`

[^livefacts]: I think should be equivalent to require the value to be valid for drop only when actually dropping it? With polonius we add additional constraints for exactly the locations where drop is used I think? Unsure, should be fine to think about this as: borrowck requires a value to be valid for drop whenever it could get dropped.

[^core]: This is the core assumption of [#110288] and [RFC 3417].

[#110288]: https://github.com/rust-lang/rust/issues/110288
[RFC 3417]: https://github.com/rust-lang/rfcs/pull/3417

## question section

### @lcnr: how do i ask a question

i want to ask a question but don't know how, how do I do it?

@lcnr: like this :3

### "trait objects do not own anything"

pnkfelixs: I assume "trait object" there means `&dyn Trait`/`&mut Trait`/`*const Trait` ...

@lcnr: I mean `dyn Trait<'a>`, I consider it easier to think about trait objects as having an explicit drop, but not owning anything. Because that's what is actually going on, even though its currently not really represented by the type system.

pnkfelix: but can't `Box<dyn Trait>` own things .... ah I see, you treat the embedded ownership as being tied to an explicit `<T as Drop>::drop` method, even if the underlying implementing type does not actually implement Drop?

lcnr: :+1: yeah, as we explicitly call `vtable.drop_in_place`, while not recursing into anything.

nikomatsakis: I always say it as more like "vtables have drop, which is defined by calling a method from the vtable". I'm not sure if this is an important distinction though.

### dropck_outlives vs needs_drop inconsistency

pnkfelix: What are the concrete negative outcomes, from a Rust programmer's perspective (vs a rustc dev's perspective) of the inconsistency here? Is it unsoundnes? Or surprising cases where code is rejected by the compiler? Or difficulty in reasoning about unsafe code soundness? Or something else?

pnkfelix: Specifically, with respect to the PhantomData inconsistency: Are all the negative outcomes there surfacing as instances of bad interactions with `#[may_dangle]` ? (Note the text here *does* provide pointers to examples of the `#[may_dangle]` problems.) Or are there other issues (that I don't see documented here)?

[Discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/326132-t-types.2Fmeetings/topic/2023-07-17.20dropck/near/376045297)

### elaboration before dropck

> As far as I know such a feature gate does not exist for doing some drop elaboration before borrowck.

nikomatsakis: There was work on this. It was meant to unblock polonius. I am not sure the current state.

Relevant MCP: https://github.com/rust-lang/compiler-team/issues/558

### "drop-live"

> During borrowck, we require a local to be valid for drop at all locations before it is dropped[2] by adding the region constraints returned by dropck_outlives. For locals whose type does not need drop, i.e. Ty::needs_drop returned false, we do not emit drop statements during mir building, so these locals are never required to be valid wrt to drop.

nikomatsakis: This is accurate, I just want to add a bit of "color" to the description. The way I think about it is that there are two distinct "liveness" computations that we perform:

* a value `v` is *use-live* at location `L` if it maybe "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`.

These "values" would be better thought of as places.

### What are the "cycle" implications of fixing the `[T;0]` inconsistency?

> Fixing the `[T; 0]` inconsistency ([#110288])

nikomatsakis: This implies that we perform const eval for the array length, right? Is that an issue? We would have to be able to do that without access to borrow check, I think that's the primary implication?

lcnr: good catch :sweat_smile: it's not an issue on stable. Given that we generally have to try to evaluate constants during typeck so any constant leaking into the type system already has to be evaluatable to avoid cycle, I don't expect this to cause more issues, even with `feature(generic_const_exprs)`.

### What does "may dangle" mean?

> `#[may_dangle]` unsafely states “this parameter is not accessed directly in the Drop implementation”.

nikomatsakis: I don't think this is the right way to describe it. Well, maybe it is! I was going to say that "may dangle" meant: "may be dropped", but actually I think that's untrue, and I guess this is the point of the text that follows? i.e., we basically want to characterize in one of 3 ways:

* values of type `T` should be *use-live* when the drop executes (chosen if there is a `Drop` impl unless there is a `#[may_dangle]` attribute)
* values of type `T` should be *drop-live* when the drop executes (chosen if the type owns a value of type `T` or (today) includes a `PhantomData<T>`, even if there is a `#[may_dangle]` attribute)
* values of type `T` don't need to be live at all when the drop executes (chosen if the type is only borrowed)

Is this an accurate summary?

lcnr: yes, though "chosen if the type owns a value of type `T` or (today) includes a `PhantomData<T>`, even if there is a `#[may_dangle]` attribute" feels less clear to me then saying "`Drop` impls requires all parameters to be live, unless they are marked with `#[may_dangle]`. In this case we only consider the parameter if it is recursively owned" which is what I wanted to state in the doc ^^

### examples of finer-grained may_dangle?

pnkfelix: Regarding the extensions `#[may_dangle(must_not_use)]` and `#[may_dangle(can_drop)]`: do we know how the existing uses of `#[may_dangle]` are going to map to each of those two new forms?

pnkfelix: E.g. what will `unsafe impl<#[may_dangle] T> Drop for Vec<T>` map to?