Function rustc_typeck::check::dropck::check_safety_of_destructor_if_necessary [] [src]

pub fn check_safety_of_destructor_if_necessary<'a, 'gcx, 'tcx>(rcx: &mut RegionCtxt<'a, 'gcx, 'tcx>,
                                                               typ: Ty<'tcx>,
                                                               span: Span,
                                                               scope: CodeExtent)
🔬 This is a nightly-only experimental API. (rustc_private)

check_safety_of_destructor_if_necessary confirms that the type expression typ conforms to the "Drop Check Rule" from the Sound Generic Drop (RFC 769).


The simplified (*) Drop Check Rule is the following:

Let v be some value (either temporary or named) and 'a be some lifetime (scope). If the type of v owns data of type D, where

then 'a must strictly outlive the scope of v.


This function is meant to by applied to the type for every expression in the program.


(*) The qualifier "simplified" is attached to the above definition of the Drop Check Rule, because it is a simplification of the original Drop Check rule, which attempted to prove that some Drop implementations could not possibly access data even if it was technically reachable, due to parametricity.

However, (1.) parametricity on its own turned out to be a necessary but insufficient condition, and (2.) future changes to the language are expected to make it impossible to ensure that a Drop implementation is actually parametric with respect to any particular type parameter. (In particular, impl specialization is expected to break the needed parametricity property beyond repair.)

Therefore we have scaled back Drop-Check to a more conservative rule that does not attempt to deduce whether a Drop implementation could not possible access data of a given lifetime; instead Drop-Check now simply assumes that if a destructor has access (direct or indirect) to a lifetime parameter, then that lifetime must be forced to outlive that destructor's dynamic extent. We then provide the unsafe_destructor_blind_to_params attribute as a way for destructor implementations to opt-out of this conservative assumption (and thus assume the obligation of ensuring that they do not access data nor invoke methods of values that have been previously dropped).