CattleTeam飞书用户7108
讲讲让我熬了几天夜的Drop Check
输入“/”快速插入内容
讲讲让我熬了几天夜的Drop Check
讲讲让我熬了几天夜的Drop Check
最近为了搞懂drop check熬了几天夜。这里收集到关于drop check的资料：
•
•
•
•
•
•
•
•
补充
•
•
Drop与析构函数
在讨论之前先理一下Drop和析构函数的关系。Drop::drop是析构函数的一部分，可选实现，编译器通过drop glue得到一个完整的析构函数。
首先，析构函数行为由值的类型所决定，一个类型T的**析构函数(Destructor)**将会做这些事情：
1.
如果T: Copy或者T == ManuallyDrop<_>，或由这些类型组成的ADT，没有析构函数。
2.
如果T: Drop，则先对其值调用<T as Drop>::drop
3.
然后递归地调用其自身所有字段的析构函数，比如
a.
T是结构体，那么则按照字段的声明顺序调用字段的析构函数
b.
T是数组，则按顺序调用元素的析构函数
c.
T是Trait Object，则对其值调用内部实际类型的析构函数
d.
...
其中编译器将步骤2和步骤3粘起来成为完整的析构函数的操作叫做drop glue。
Drop glue的产物就是std::ptr::drop_in_place
没有析构函数的类型，在MIR阶段不会插入DROP(var)的指令，不会进行析构，于是也不会进行drop check。
为什么要check？
众所周知，rust通过RAII来管理内存——值会在退出作用域的时候被析构。但按照目前的规定的析构顺序，如果变量是先声明先析构，就有可能发生后析构的值仍然借用着已经析构了的值的情况，从而有可能发生UAF(use after free)。
于是需要引入一个drop check：保证一个值在析构时，其析构函数不会访问到一个悬垂引用&'a _所引用的内存。
与borrow check中一般的规则不同，borrow check在使用一个值的时候是不允许值里有悬垂引用的，但析构函数有些情况是允许的——因为大多数类型drop glue产生的析构函数不会通过悬垂引用去访问内存，比如(&str, String)。从这个角度来说drop check的会比borrow checker的一般规则要弱一些。
另外borrow check也不能覆盖所有drop check所检查的情况。一些类型内部的析构顺序（比如数组会从前到后析构元素），并不会在MIR上体现出来，borrow checker无法进行检查。于是从这个角度来说，drop check还是borrow check的补充。
那么drop check 的具体规则是什么呢？
年轻人的第一个drop check
从一个例子讲起：
代码块
//! 例子1
struct Foo<T: Debug>(T);
impl<T: Debug> Drop for Foo<T> {
fn drop(&mut self) {
println!("dropping Foo with {:?}", self.0);
}
}
fn main() {
let _foo;
let s = String::from("123");
_foo = Foo(&*s);
}
/* 编译报错：
error[E0597]: `s` does not live long enough
--> src/main.rs:16:23
|
16 | _foo = Foo(&*s);
| ^ borrowed value does not live long enough
17 | }
| -
| |
| `s` dropped here while still borrowed
| borrow might be used here, when `_foo` is dropped and runs the `Drop` code for type `Foo`
|
= note: values in a scope are dropped in the opposite order they are defined
*/