Drop Check

We have seen how lifetimes provide us some fairly simple rules for ensuringthat we never read dangling references. However up to this point we have only everinteracted with the outlives relationship in an inclusive manner. That is,when we talked about 'a: 'b, it was ok for 'a to live exactly as long as'b. At first glance, this seems to be a meaningless distinction. Nothing evergets dropped at the same time as another, right? This is why we used thefollowing desugaring of let statements:

  1. let x;
  2. let y;
  1. {
  2.     let x;
  3.     {
  4.         let y;
  5.     }
  6. }

There are some more complex situations which are not possible to desugar usingscopes, but the order is still defined ‒ variables are dropped in the reverseorder of their definition, fields of structs and tuples in order of theirdefinition. There are some more details about order of drop in [rfc1875].

Let’s do this:

  1. let tuple = (vec![], vec![]);

The left vector is dropped first. But does it mean the right one strictlyoutlives it in the eyes of the borrow checker? The answer to this question isno. The borrow checker could track fields of tuples separately, but it wouldstill be unable to decide what outlives what in case of vector elements, whichare dropped manually via pure-library code the borrow checker doesn’tunderstand.

So why do we care? We care because if the type system isn’t careful, it couldaccidentally make dangling pointers. Consider the following simple program:

  1. struct Inspector<'a>(&'a u8);
  3. struct World<'a> {
  4.     inspector: Option<Inspector<'a>>,
  5.     days: Box<u8>,
  6. }
  8. fn main() {
  9.     let mut world = World {
  10.         inspector: None,
  11.         days: Box::new(1),
  12.     };
  13.     world.inspector = Some(Inspector(&world.days));
  14. }

This program is totally sound and compiles today. The fact that days does notstrictly outlive inspector doesn’t matter. As long as the inspector isalive, so is days.

However if we add a destructor, the program will no longer compile!

  1. struct Inspector<'a>(&'a u8);
  3. impl<'a> Drop for Inspector<'a> {
  4.     fn drop(&mut self) {
  5.         println!("I was only {} days from retirement!", self.0);
  6.     }
  7. }
  9. struct World<'a> {
  10.     inspector: Option<Inspector<'a>>,
  11.     days: Box<u8>,
  12. }
  14. fn main() {
  15.     let mut world = World {
  16.         inspector: None,
  17.         days: Box::new(1),
  18.     };
  19.     world.inspector = Some(Inspector(&world.days));
  20.     // Let's say `days` happens to get dropped first.
  21.     // Then when Inspector is dropped, it will try to read free'd memory!
  22. }
  1. error[E0597]: `world.days` does not live long enough
  2.   --> src/main.rs:20:39
  3.    |
  4. 20 |     world.inspector = Some(Inspector(&world.days));
  5.    |                                       ^^^^^^^^^^ borrowed value does not live long enough
  6. ...
  7. 23 | }
  8.    | - `world.days` dropped here while still borrowed
  9.    |
  10.    = note: values in a scope are dropped in the opposite order they are created

You can try changing the order of fields or use a tuple instead of the struct,it’ll still not compile.

Implementing Drop lets the Inspector execute some arbitrary code during itsdeath. This means it can potentially observe that types that are supposed tolive as long as it does actually were destroyed first.

Interestingly, only generic types need to worry about this. If they aren’tgeneric, then the only lifetimes they can harbor are 'static, which will trulylive forever. This is why this problem is referred to as sound generic drop.Sound generic drop is enforced by the drop checker. As of this writing, someof the finer details of how the drop checker validates types is totally up inthe air. However The Big Rule is the subtlety that we have focused on this wholesection:

For a generic type to soundly implement drop, its generics arguments muststrictly outlive it.

Obeying this rule is (usually) necessary to satisfy the borrowchecker; obeying it is sufficient but not necessary to besound. That is, if your type obeys this rule then it’s definitelysound to drop.

The reason that it is not always necessary to satisfy the above ruleis that some Drop implementations will not access borrowed data eventhough their type gives them the capability for such access, or because we knowthe specific drop order and the borrowed data is still fine even if the borrowchecker doesn’t know that.

For example, this variant of the above Inspector example will neveraccess borrowed data:

  1. struct Inspector<'a>(&'a u8, &'static str);
  3. impl<'a> Drop for Inspector<'a> {
  4.     fn drop(&mut self) {
  5.         println!("Inspector(_, {}) knows when *not* to inspect.", self.1);
  6.     }
  7. }
  9. struct World<'a> {
  10.     inspector: Option<Inspector<'a>>,
  11.     days: Box<u8>,
  12. }
  14. fn main() {
  15.     let mut world = World {
  16.         inspector: None,
  17.         days: Box::new(1),
  18.     };
  19.     world.inspector = Some(Inspector(&world.days, "gadget"));
  20.     // Let's say `days` happens to get dropped first.
  21.     // Even when Inspector is dropped, its destructor will not access the
  22.     // borrowed `days`.
  23. }

Likewise, this variant will also never access borrowed data:

  1. struct Inspector<T>(T, &'static str);
  3. impl<T> Drop for Inspector<T> {
  4.     fn drop(&mut self) {
  5.         println!("Inspector(_, {}) knows when *not* to inspect.", self.1);
  6.     }
  7. }
  9. struct World<T> {
  10.     inspector: Option<Inspector<T>>,
  11.     days: Box<u8>,
  12. }
  14. fn main() {
  15.     let mut world = World {
  16.         inspector: None,
  17.         days: Box::new(1),
  18.     };
  19.     world.inspector = Some(Inspector(&world.days, "gadget"));
  20.     // Let's say `days` happens to get dropped first.
  21.     // Even when Inspector is dropped, its destructor will not access the
  22.     // borrowed `days`.
  23. }

However, both of the above variants are rejected by the borrowchecker during the analysis of fn main, saying that days does notlive long enough.

The reason is that the borrow checking analysis of main does notknow about the internals of each Inspector‘s Drop implementation. Asfar as the borrow checker knows while it is analyzing main, the bodyof an inspector’s destructor might access that borrowed data.

Therefore, the drop checker forces all borrowed data in a value tostrictly outlive that value.

An Escape Hatch

The precise rules that govern drop checking may be less restrictive inthe future.

The current analysis is deliberately conservative and trivial; it forces allborrowed data in a value to outlive that value, which is certainly sound.

Future versions of the language may make the analysis more precise, toreduce the number of cases where sound code is rejected as unsafe.This would help address cases such as the two Inspectors above thatknow not to inspect during destruction.

In the meantime, there is an unstable attribute that one can use toassert (unsafely) that a generic type’s destructor is guaranteed tonot access any expired data, even if its type gives it the capabilityto do so.

That attribute is called may_dangle and was introduced in RFC 1327.To deploy it on the Inspector from above, we would write:

  1. #![feature(dropck_eyepatch)]
  3. struct Inspector<'a>(&'a u8, &'static str);
  5. unsafe impl<#[may_dangle] 'a> Drop for Inspector<'a> {
  6.     fn drop(&mut self) {
  7.         println!("Inspector(_, {}) knows when *not* to inspect.", self.1);
  8.     }
  9. }
  11. struct World<'a> {
  12.     days: Box<u8>,
  13.     inspector: Option<Inspector<'a>>,
  14. }
  16. fn main() {
  17.     let mut world = World {
  18.         inspector: None,
  19.         days: Box::new(1),
  20.     };
  21.     world.inspector = Some(Inspector(&world.days, "gatget"));
  22. }

Use of this attribute requires the Drop impl to be marked unsafe because thecompiler is not checking the implicit assertion that no potentially expired data(e.g. self.0 above) is accessed.

The attribute can be applied to any number of lifetime and type parameters. Inthe following example, we assert that we access no data behind a reference oflifetime 'b and that the only uses of T will be moves or drops, but omitthe attribute from 'a and U, because we do access data with that lifetimeand that type:

  1. use std::fmt::Display;
  3. struct Inspector<'a, 'b, T, U: Display>(&'a u8, &'b u8, T, U);
  5. unsafe impl<'a, #[may_dangle] 'b, #[may_dangle] T, U: Display> Drop for Inspector<'a, 'b, T, U> {
  6.     fn drop(&mut self) {
  7.         println!("Inspector({}, _, _, {})", self.0, self.3);
  8.     }
  9. }

It is sometimes obvious that no such access can occur, like the case above.However, when dealing with a generic type parameter, such access canoccur indirectly. Examples of such indirect access are:

  • invoking a callback,
  • via a trait method call.

(Future changes to the language, such as impl specialization, may addother avenues for such indirect access.)

Here is an example of invoking a callback:

  1. struct Inspector<T>(T, &'static str, Box<for <'r> fn(&'r T) -> String>);
  3. impl<T> Drop for Inspector<T> {
  4.     fn drop(&mut self) {
  5.         // The `self.2` call could access a borrow e.g. if `T` is `&'a _`.
  6.         println!("Inspector({}, {}) unwittingly inspects expired data.",
  7.                  (self.2)(&self.0), self.1);
  8.     }
  9. }

Here is an example of a trait method call:

  1. use std::fmt;
  3. struct Inspector<T: fmt::Display>(T, &'static str);
  5. impl<T: fmt::Display> Drop for Inspector<T> {
  6.     fn drop(&mut self) {
  7.         // There is a hidden call to `<T as Display>::fmt` below, which
  8.         // could access a borrow e.g. if `T` is `&'a _`
  9.         println!("Inspector({}, {}) unwittingly inspects expired data.",
  10.                  self.0, self.1);
  11.     }
  12. }

And of course, all of these accesses could be further hidden withinsome other method invoked by the destructor, rather than being writtendirectly within it.

In all of the above cases where the &'a u8 is accessed in thedestructor, adding the #[may_dangle]attribute makes the type vulnerable to misuse that the borrowerchecker will not catch, inviting havoc. It is better to avoid addingthe attribute.

A related side note about drop order

While the drop order of fields inside a struct is defined, relying on it isfragile and subtle. When the order matters, it is better to use theManuallyDrop wrapper.

Is that all about drop checker?

It turns out that when writing unsafe code, we generally don’t need toworry at all about doing the right thing for the drop checker. However thereis one special case that you need to worry about, which we will look at inthe next section.