Skip to content

Commit 4d6d601

Browse files
authored
Add dropck documentation (rust-lang#1767)
1 parent ea6c881 commit 4d6d601

File tree

2 files changed

+155
-0
lines changed

2 files changed

+155
-0
lines changed

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

0 commit comments

Comments
 (0)