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)
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
- (1.)
D
has a lifetime- or type-parametric Drop implementation, (where thatDrop
implementation does not opt-out of this check via theunsafe_destructor_blind_to_params
attribute), and - (2.) the structure of
D
can reach a reference of type&'a _
,
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).