Skip to content

Commit 302c8e3

Browse files
committed
Add dropck documentation
1 parent b123ab4 commit 302c8e3

File tree

2 files changed

+153
-0
lines changed

2 files changed

+153
-0
lines changed

src/SUMMARY.md

+1
Original file line numberDiff line numberDiff line change
@@ -139,6 +139,7 @@
139139
- [Tracking moves and initialization](./borrow_check/moves_and_initialization.md)
140140
- [Move paths](./borrow_check/moves_and_initialization/move_paths.md)
141141
- [MIR type checker](./borrow_check/type_check.md)
142+
- [Drop check](./borrow_check/drop_check.md)
142143
- [Region inference](./borrow_check/region_inference.md)
143144
- [Constraint propagation](./borrow_check/region_inference/constraint_propagation.md)
144145
- [Lifetime parameters](./borrow_check/region_inference/lifetime_parameters.md)

src/borrow_check/drop_check.md

+152
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,152 @@
1+
# Drop Check
2+
3+
We generally require the type of locals to be well-formed whenever the
4+
local is used. This includes proving the where-bounds of the local and
5+
also requires all regions used by it to be live.
6+
7+
The only exception to this is the implicitly dropping values when they
8+
go out of scope. This does not necessarily require the value to be live:
9+
10+
```rust
11+
fn main() {
12+
let x = vec![];
13+
{
14+
let y = String::from("I am temporary");
15+
x.push(&y);
16+
}
17+
// `x` goes out of scope here, after the reference to `y`
18+
// is invalidated. This means that while dropping `x` its type
19+
// is not well-formed as it contain regions which are not live.
20+
}
21+
```
22+
23+
This is only sound if dropping the value does not try to access any dead
24+
region. The code responsible for this is `dropck_outlives`.
25+
26+
The rest of this section uses the following type definition for a type
27+
which requires its region parameter to be live:
28+
29+
```rust
30+
struct PrintOnDrop<'a>(&'a str);
31+
impl<'a> Drop for PrintOnDrop<'_> {
32+
fn drop(&mut self) {
33+
println!("{}", self.0);
34+
}
35+
}
36+
```
37+
38+
## How values are dropped
39+
40+
At its core, a value of type `T` is dropped by executing its "drop
41+
glue". Drop glue is compiler generated and first calls `<T as
42+
Drop>::drop` and then recursively calls the drop glue of any recursively
43+
owned values.
44+
45+
- If `T` has an explicit `Drop` impl, call `<T as Drop>::drop`.
46+
- Regardless of whether `T` implements `Drop`, recurse into all values
47+
*owned* by `T`:
48+
- references, raw pointers, function pointers, function items, trait
49+
objects[^traitobj], and scalars do not own anything.
50+
- tuples, slices, and arrays consider their elements to be owned.
51+
For arrays of length zero we do not own any value of the element
52+
type.
53+
- all fields (of all variants) of ADTs are considered owned. We
54+
consider all variants for enums. The exception here is
55+
`ManuallyDrop<U>` which is not considered to own `U`.
56+
`PhantomData<U>` also does not own anything.
57+
closures and generators own their captured upvars.
58+
59+
Whether a type has drop glue is returned by [`fn
60+
Ty::needs_drop`](https://github.com/rust-lang/rust/blob/320b412f9c55bf480d26276ff0ab480e4ecb29c0/compiler/rustc_middle/src/ty/util.rs#L1086-L1108).
61+
62+
### Partially dropping a local
63+
64+
For types which do not implement `Drop` themselves, we can also
65+
partially move parts of the value before dropping the rest. In this case
66+
only the drop glue for the not-yet moved values is called, e.g.
67+
68+
```rust
69+
fn main() {
70+
let mut x = (PrintOnDrop("third"), PrintOnDrop("first"));
71+
drop(x.1);
72+
println!("second")
73+
}
74+
```
75+
76+
During MIR building we assume that a local may get dropped whenever it
77+
goes out of scope *as long as its type needs drop*. Computing the exact
78+
drop glue for a variable happens **after** borrowck in the
79+
`ElaborateDrops` pass. This means that even if some part of the local
80+
have been dropped previously, dropck still requires this value to be
81+
live. This is the case even if we completely moved a local.
82+
83+
```rust
84+
fn main() {
85+
let mut x;
86+
{
87+
let temp = String::from("I am temporary");
88+
x = PrintOnDrop(&temp);
89+
drop(x);
90+
}
91+
} //~ ERROR `temp` does not live long enough.
92+
```
93+
94+
It should be possible to add some amount of drop elaboration before
95+
borrowck, allowing this example to compile. There is an unstable feature
96+
to move drop elaboration before const checking:
97+
[#73255](https://github.com/rust-lang/rust/issues/73255). Such a feature
98+
gate does not exist for doing some drop elaboration before borrowck,
99+
although there's a [relevant
100+
MCP](https://github.com/rust-lang/compiler-team/issues/558).
101+
102+
[^traitobj]: you can consider trait objects to have a builtin `Drop`
103+
implementation which directly uses the `drop_in_place` provided by the
104+
vtable. This `Drop` implementation requires all its generic parameters
105+
to be live.
106+
107+
### `dropck_outlives`
108+
109+
There are two distinct "liveness" computations that we perform:
110+
111+
* a value `v` is *use-live* at location `L` if it maybe "used" later; a
112+
*use* here is basically anything that is not a *drop*
113+
* a value `v` is *drop-live* at location `L` if it maybe dropped later
114+
115+
When things are *use-live*, their entire type must be valid at `L`. When
116+
they are *drop-live*, all regions that are required by dropck must be
117+
valid at `L`. These "values" would be better thought of as places.
118+
119+
The constraints computed by `dropck_outlives` for a type closely match
120+
the generated drop glue for that type. Unlike drop glue,
121+
`dropck_outlives` cares about the types of owned values, not the values
122+
itself. For a value of type `T`
123+
124+
- if `T` has an explicit `Drop`, require all generic arguments to be
125+
live, unless they are marked with `#[may_dangle]` in which case they
126+
are fully ignored
127+
- regardless of whether `T` has an explicit `Drop`, recurse into all
128+
types *owned* by `T`
129+
- references, raw pointers, function pointers, function items, trait
130+
objects[^traitobj], and scalars do not own anything.
131+
- tuples, slices and arrays consider their element type to be owned.
132+
**For arrays we currently do not check whether their length is
133+
zero**.
134+
- all fields (of all variants) of ADTs are considered owned. The
135+
exception here is `ManuallyDrop<U>` which is not considered to own
136+
`U`. **We consider `PhantomData<U>` to own `U`**.
137+
- closures and generators own their captured upvars.
138+
139+
The sections marked in bold are cases where `dropck_outlives` considers
140+
types to be owned which are ignored by `Ty::needs_drop`. We only rely on
141+
`dropck_outlives` if `Ty::needs_drop` for the containing local returned
142+
`true`.This means liveness requirements can change depending on whether
143+
a type is contained in a larger local. **This is inconsistent, and
144+
should be fixed: an example [for
145+
arrays](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=8b5f5f005a03971b22edb1c20c5e6cbe)
146+
and [for
147+
`PhantomData`](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=44c6e2b1fae826329fd54c347603b6c8).**[^core]
148+
149+
One possible way these inconsistencies can be fixed is by MIR building
150+
to be more pessimistic, probably by making `Ty::needs_drop` weaker, or
151+
alternatively, changing `dropck_outlives` to be more precise, requiring
152+
fewer regions to be live.

0 commit comments

Comments
 (0)