2019-05-17 23:55:04 +02:00
|
|
|
use rustc::mir::{self, Body, Location};
|
Revised mir-dataflow.
Incorporates many fixes contributed by arielb1.
----
revise borrowck::mir::dataflow code to allow varying domain for bitvectors.
This particular code implements the `BitDenotation` trait for three
analyses:
* `MovingOutStatements`, which, like `borrowck::move_data`, maps each
bit-index to a move instruction, and a 1 means "the effect of this
move reaches this point" (and the assigned l-value, if a scoped
declaration, is still in scope).
* `MaybeInitializedLvals`, which maps each bit-index to an l-value.
A 1 means "there exists a control flow path to this point that
initializes the associated l-value."
* `MaybeUninitializedLvals`, which maps each bit-index to an l-value
A 1 means "there exists a control flow path to this point that
de-initializes the associated l-value."
----
Revised `graphviz` dataflow-rendering support in `borrowck::mir`.
One big difference is that this code is now parameterized over the
`BitDenotation`, so that it can be used to render dataflow results
independent of how the dataflow bitvectors are interpreted; see where
reference to `MoveOut` is replaced by the type parameter `D`.
----
Factor out routine to query subattributes in `#[rustc_mir(..)]`.
(Later commits build upon this for some unit testing and instrumentation.)
----
thread through a tcx so that I can query types of lvalues as part of analysis.
----
Revised `BitDenotation::Ctxt`, allowing variation beyond `MoveData`.
The main motivation is to ease threading through a `TyCtxt`.
(In hindsight it might have been better to instead attach the `TyCtxt`
to each of the different dataflow implementations, but that would
require e.g. switching away from having a `Default` impl, so I am
leaving that experiment for another time.)
2016-05-02 15:50:27 +02:00
|
|
|
use rustc::ty::{self, TyCtxt};
|
2019-02-08 06:28:15 +09:00
|
|
|
use crate::util::elaborate_drops::DropFlagState;
|
2016-01-25 14:34:34 +01:00
|
|
|
|
2017-07-04 12:38:48 +02:00
|
|
|
use super::{MoveDataParamEnv};
|
2017-06-26 14:57:26 +02:00
|
|
|
use super::indexes::MovePathIndex;
|
2017-11-27 08:06:36 +00:00
|
|
|
use super::move_paths::{MoveData, LookupResult, InitKind};
|
2017-06-26 14:57:26 +02:00
|
|
|
|
|
|
|
pub fn move_path_children_matching<'tcx, F>(move_data: &MoveData<'tcx>,
|
2016-05-17 02:26:18 +03:00
|
|
|
path: MovePathIndex,
|
|
|
|
mut cond: F)
|
|
|
|
-> Option<MovePathIndex>
|
2019-08-24 19:49:08 -04:00
|
|
|
where F: FnMut(&mir::PlaceElem<'tcx>) -> bool
|
2016-05-17 02:26:18 +03:00
|
|
|
{
|
2016-06-11 23:47:28 +03:00
|
|
|
let mut next_child = move_data.move_paths[path].first_child;
|
2016-05-17 02:26:18 +03:00
|
|
|
while let Some(child_index) = next_child {
|
2019-08-24 19:49:08 -04:00
|
|
|
let move_path_children = &move_data.move_paths[child_index];
|
|
|
|
if let Some(elem) = move_path_children.place.projection.last() {
|
|
|
|
if cond(elem) {
|
|
|
|
return Some(child_index)
|
|
|
|
}
|
2016-05-17 02:26:18 +03:00
|
|
|
}
|
2019-08-24 19:49:08 -04:00
|
|
|
next_child = move_path_children.next_sibling;
|
2016-05-17 02:26:18 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
None
|
|
|
|
}
|
|
|
|
|
2016-06-06 16:16:44 +02:00
|
|
|
/// When enumerating the child fragments of a path, don't recurse into
|
|
|
|
/// paths (1.) past arrays, slices, and pointers, nor (2.) into a type
|
|
|
|
/// that implements `Drop`.
|
|
|
|
///
|
2017-12-01 14:31:47 +02:00
|
|
|
/// Places behind references or arrays are not tracked by elaboration
|
2016-06-06 16:16:44 +02:00
|
|
|
/// and are always assumed to be initialized when accessible. As
|
|
|
|
/// references and indexes can be reseated, trying to track them can
|
|
|
|
/// only lead to trouble.
|
|
|
|
///
|
2017-12-01 14:31:47 +02:00
|
|
|
/// Places behind ADT's with a Drop impl are not tracked by
|
2016-06-06 16:16:44 +02:00
|
|
|
/// elaboration since they can never have a drop-flag state that
|
|
|
|
/// differs from that of the parent with the Drop impl.
|
|
|
|
///
|
|
|
|
/// In both cases, the contents can only be accessed if and only if
|
|
|
|
/// their parents are initialized. This implies for example that there
|
|
|
|
/// is no need to maintain separate drop flags to track such state.
|
2019-02-08 14:53:55 +01:00
|
|
|
//
|
|
|
|
// FIXME: we have to do something for moving slice patterns.
|
2019-06-14 00:48:52 +03:00
|
|
|
fn place_contents_drop_state_cannot_differ<'tcx>(
|
|
|
|
tcx: TyCtxt<'tcx>,
|
2019-06-12 00:11:55 +03:00
|
|
|
body: &Body<'tcx>,
|
|
|
|
place: &mir::Place<'tcx>,
|
|
|
|
) -> bool {
|
2019-06-03 18:26:48 -04:00
|
|
|
let ty = place.ty(body, tcx).ty;
|
2016-06-06 16:16:44 +02:00
|
|
|
match ty.sty {
|
2018-08-22 01:35:02 +01:00
|
|
|
ty::Array(..) => {
|
2017-11-28 15:48:23 +03:00
|
|
|
debug!("place_contents_drop_state_cannot_differ place: {:?} ty: {:?} => false",
|
|
|
|
place, ty);
|
|
|
|
false
|
|
|
|
}
|
2018-08-22 01:35:02 +01:00
|
|
|
ty::Slice(..) | ty::Ref(..) | ty::RawPtr(..) => {
|
2017-12-01 14:39:51 +02:00
|
|
|
debug!("place_contents_drop_state_cannot_differ place: {:?} ty: {:?} refd => true",
|
|
|
|
place, ty);
|
2016-06-06 16:16:44 +02:00
|
|
|
true
|
|
|
|
}
|
2018-08-22 01:35:02 +01:00
|
|
|
ty::Adt(def, _) if (def.has_dtor(tcx) && !def.is_box()) || def.is_union() => {
|
2017-12-01 14:39:51 +02:00
|
|
|
debug!("place_contents_drop_state_cannot_differ place: {:?} ty: {:?} Drop => true",
|
|
|
|
place, ty);
|
2016-06-06 16:16:44 +02:00
|
|
|
true
|
|
|
|
}
|
|
|
|
_ => {
|
|
|
|
false
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-06-14 00:48:52 +03:00
|
|
|
pub(crate) fn on_lookup_result_bits<'tcx, F>(
|
|
|
|
tcx: TyCtxt<'tcx>,
|
2019-06-03 18:26:48 -04:00
|
|
|
body: &Body<'tcx>,
|
2016-06-11 23:47:28 +03:00
|
|
|
move_data: &MoveData<'tcx>,
|
|
|
|
lookup_result: LookupResult,
|
2019-06-12 00:11:55 +03:00
|
|
|
each_child: F,
|
|
|
|
) where
|
|
|
|
F: FnMut(MovePathIndex),
|
2016-06-11 23:47:28 +03:00
|
|
|
{
|
|
|
|
match lookup_result {
|
|
|
|
LookupResult::Parent(..) => {
|
|
|
|
// access to untracked value - do not touch children
|
|
|
|
}
|
|
|
|
LookupResult::Exact(e) => {
|
2019-06-03 18:26:48 -04:00
|
|
|
on_all_children_bits(tcx, body, move_data, e, each_child)
|
2016-06-11 23:47:28 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-06-14 00:48:52 +03:00
|
|
|
pub(crate) fn on_all_children_bits<'tcx, F>(
|
|
|
|
tcx: TyCtxt<'tcx>,
|
2019-06-03 18:26:48 -04:00
|
|
|
body: &Body<'tcx>,
|
Revised mir-dataflow.
Incorporates many fixes contributed by arielb1.
----
revise borrowck::mir::dataflow code to allow varying domain for bitvectors.
This particular code implements the `BitDenotation` trait for three
analyses:
* `MovingOutStatements`, which, like `borrowck::move_data`, maps each
bit-index to a move instruction, and a 1 means "the effect of this
move reaches this point" (and the assigned l-value, if a scoped
declaration, is still in scope).
* `MaybeInitializedLvals`, which maps each bit-index to an l-value.
A 1 means "there exists a control flow path to this point that
initializes the associated l-value."
* `MaybeUninitializedLvals`, which maps each bit-index to an l-value
A 1 means "there exists a control flow path to this point that
de-initializes the associated l-value."
----
Revised `graphviz` dataflow-rendering support in `borrowck::mir`.
One big difference is that this code is now parameterized over the
`BitDenotation`, so that it can be used to render dataflow results
independent of how the dataflow bitvectors are interpreted; see where
reference to `MoveOut` is replaced by the type parameter `D`.
----
Factor out routine to query subattributes in `#[rustc_mir(..)]`.
(Later commits build upon this for some unit testing and instrumentation.)
----
thread through a tcx so that I can query types of lvalues as part of analysis.
----
Revised `BitDenotation::Ctxt`, allowing variation beyond `MoveData`.
The main motivation is to ease threading through a `TyCtxt`.
(In hindsight it might have been better to instead attach the `TyCtxt`
to each of the different dataflow implementations, but that would
require e.g. switching away from having a `Default` impl, so I am
leaving that experiment for another time.)
2016-05-02 15:50:27 +02:00
|
|
|
move_data: &MoveData<'tcx>,
|
|
|
|
move_path_index: MovePathIndex,
|
2019-06-12 00:11:55 +03:00
|
|
|
mut each_child: F,
|
|
|
|
) where
|
|
|
|
F: FnMut(MovePathIndex),
|
Revised mir-dataflow.
Incorporates many fixes contributed by arielb1.
----
revise borrowck::mir::dataflow code to allow varying domain for bitvectors.
This particular code implements the `BitDenotation` trait for three
analyses:
* `MovingOutStatements`, which, like `borrowck::move_data`, maps each
bit-index to a move instruction, and a 1 means "the effect of this
move reaches this point" (and the assigned l-value, if a scoped
declaration, is still in scope).
* `MaybeInitializedLvals`, which maps each bit-index to an l-value.
A 1 means "there exists a control flow path to this point that
initializes the associated l-value."
* `MaybeUninitializedLvals`, which maps each bit-index to an l-value
A 1 means "there exists a control flow path to this point that
de-initializes the associated l-value."
----
Revised `graphviz` dataflow-rendering support in `borrowck::mir`.
One big difference is that this code is now parameterized over the
`BitDenotation`, so that it can be used to render dataflow results
independent of how the dataflow bitvectors are interpreted; see where
reference to `MoveOut` is replaced by the type parameter `D`.
----
Factor out routine to query subattributes in `#[rustc_mir(..)]`.
(Later commits build upon this for some unit testing and instrumentation.)
----
thread through a tcx so that I can query types of lvalues as part of analysis.
----
Revised `BitDenotation::Ctxt`, allowing variation beyond `MoveData`.
The main motivation is to ease threading through a `TyCtxt`.
(In hindsight it might have been better to instead attach the `TyCtxt`
to each of the different dataflow implementations, but that would
require e.g. switching away from having a `Default` impl, so I am
leaving that experiment for another time.)
2016-05-02 15:50:27 +02:00
|
|
|
{
|
2019-06-14 00:48:52 +03:00
|
|
|
fn is_terminal_path<'tcx>(
|
|
|
|
tcx: TyCtxt<'tcx>,
|
2019-06-03 18:26:48 -04:00
|
|
|
body: &Body<'tcx>,
|
Revised mir-dataflow.
Incorporates many fixes contributed by arielb1.
----
revise borrowck::mir::dataflow code to allow varying domain for bitvectors.
This particular code implements the `BitDenotation` trait for three
analyses:
* `MovingOutStatements`, which, like `borrowck::move_data`, maps each
bit-index to a move instruction, and a 1 means "the effect of this
move reaches this point" (and the assigned l-value, if a scoped
declaration, is still in scope).
* `MaybeInitializedLvals`, which maps each bit-index to an l-value.
A 1 means "there exists a control flow path to this point that
initializes the associated l-value."
* `MaybeUninitializedLvals`, which maps each bit-index to an l-value
A 1 means "there exists a control flow path to this point that
de-initializes the associated l-value."
----
Revised `graphviz` dataflow-rendering support in `borrowck::mir`.
One big difference is that this code is now parameterized over the
`BitDenotation`, so that it can be used to render dataflow results
independent of how the dataflow bitvectors are interpreted; see where
reference to `MoveOut` is replaced by the type parameter `D`.
----
Factor out routine to query subattributes in `#[rustc_mir(..)]`.
(Later commits build upon this for some unit testing and instrumentation.)
----
thread through a tcx so that I can query types of lvalues as part of analysis.
----
Revised `BitDenotation::Ctxt`, allowing variation beyond `MoveData`.
The main motivation is to ease threading through a `TyCtxt`.
(In hindsight it might have been better to instead attach the `TyCtxt`
to each of the different dataflow implementations, but that would
require e.g. switching away from having a `Default` impl, so I am
leaving that experiment for another time.)
2016-05-02 15:50:27 +02:00
|
|
|
move_data: &MoveData<'tcx>,
|
2019-06-12 00:11:55 +03:00
|
|
|
path: MovePathIndex,
|
|
|
|
) -> bool {
|
2017-12-01 14:39:51 +02:00
|
|
|
place_contents_drop_state_cannot_differ(
|
2019-06-03 18:26:48 -04:00
|
|
|
tcx, body, &move_data.move_paths[path].place)
|
Revised mir-dataflow.
Incorporates many fixes contributed by arielb1.
----
revise borrowck::mir::dataflow code to allow varying domain for bitvectors.
This particular code implements the `BitDenotation` trait for three
analyses:
* `MovingOutStatements`, which, like `borrowck::move_data`, maps each
bit-index to a move instruction, and a 1 means "the effect of this
move reaches this point" (and the assigned l-value, if a scoped
declaration, is still in scope).
* `MaybeInitializedLvals`, which maps each bit-index to an l-value.
A 1 means "there exists a control flow path to this point that
initializes the associated l-value."
* `MaybeUninitializedLvals`, which maps each bit-index to an l-value
A 1 means "there exists a control flow path to this point that
de-initializes the associated l-value."
----
Revised `graphviz` dataflow-rendering support in `borrowck::mir`.
One big difference is that this code is now parameterized over the
`BitDenotation`, so that it can be used to render dataflow results
independent of how the dataflow bitvectors are interpreted; see where
reference to `MoveOut` is replaced by the type parameter `D`.
----
Factor out routine to query subattributes in `#[rustc_mir(..)]`.
(Later commits build upon this for some unit testing and instrumentation.)
----
thread through a tcx so that I can query types of lvalues as part of analysis.
----
Revised `BitDenotation::Ctxt`, allowing variation beyond `MoveData`.
The main motivation is to ease threading through a `TyCtxt`.
(In hindsight it might have been better to instead attach the `TyCtxt`
to each of the different dataflow implementations, but that would
require e.g. switching away from having a `Default` impl, so I am
leaving that experiment for another time.)
2016-05-02 15:50:27 +02:00
|
|
|
}
|
|
|
|
|
2019-06-14 00:48:52 +03:00
|
|
|
fn on_all_children_bits<'tcx, F>(
|
|
|
|
tcx: TyCtxt<'tcx>,
|
2019-06-03 18:26:48 -04:00
|
|
|
body: &Body<'tcx>,
|
Revised mir-dataflow.
Incorporates many fixes contributed by arielb1.
----
revise borrowck::mir::dataflow code to allow varying domain for bitvectors.
This particular code implements the `BitDenotation` trait for three
analyses:
* `MovingOutStatements`, which, like `borrowck::move_data`, maps each
bit-index to a move instruction, and a 1 means "the effect of this
move reaches this point" (and the assigned l-value, if a scoped
declaration, is still in scope).
* `MaybeInitializedLvals`, which maps each bit-index to an l-value.
A 1 means "there exists a control flow path to this point that
initializes the associated l-value."
* `MaybeUninitializedLvals`, which maps each bit-index to an l-value
A 1 means "there exists a control flow path to this point that
de-initializes the associated l-value."
----
Revised `graphviz` dataflow-rendering support in `borrowck::mir`.
One big difference is that this code is now parameterized over the
`BitDenotation`, so that it can be used to render dataflow results
independent of how the dataflow bitvectors are interpreted; see where
reference to `MoveOut` is replaced by the type parameter `D`.
----
Factor out routine to query subattributes in `#[rustc_mir(..)]`.
(Later commits build upon this for some unit testing and instrumentation.)
----
thread through a tcx so that I can query types of lvalues as part of analysis.
----
Revised `BitDenotation::Ctxt`, allowing variation beyond `MoveData`.
The main motivation is to ease threading through a `TyCtxt`.
(In hindsight it might have been better to instead attach the `TyCtxt`
to each of the different dataflow implementations, but that would
require e.g. switching away from having a `Default` impl, so I am
leaving that experiment for another time.)
2016-05-02 15:50:27 +02:00
|
|
|
move_data: &MoveData<'tcx>,
|
|
|
|
move_path_index: MovePathIndex,
|
2019-06-12 00:11:55 +03:00
|
|
|
each_child: &mut F,
|
|
|
|
) where
|
|
|
|
F: FnMut(MovePathIndex),
|
Revised mir-dataflow.
Incorporates many fixes contributed by arielb1.
----
revise borrowck::mir::dataflow code to allow varying domain for bitvectors.
This particular code implements the `BitDenotation` trait for three
analyses:
* `MovingOutStatements`, which, like `borrowck::move_data`, maps each
bit-index to a move instruction, and a 1 means "the effect of this
move reaches this point" (and the assigned l-value, if a scoped
declaration, is still in scope).
* `MaybeInitializedLvals`, which maps each bit-index to an l-value.
A 1 means "there exists a control flow path to this point that
initializes the associated l-value."
* `MaybeUninitializedLvals`, which maps each bit-index to an l-value
A 1 means "there exists a control flow path to this point that
de-initializes the associated l-value."
----
Revised `graphviz` dataflow-rendering support in `borrowck::mir`.
One big difference is that this code is now parameterized over the
`BitDenotation`, so that it can be used to render dataflow results
independent of how the dataflow bitvectors are interpreted; see where
reference to `MoveOut` is replaced by the type parameter `D`.
----
Factor out routine to query subattributes in `#[rustc_mir(..)]`.
(Later commits build upon this for some unit testing and instrumentation.)
----
thread through a tcx so that I can query types of lvalues as part of analysis.
----
Revised `BitDenotation::Ctxt`, allowing variation beyond `MoveData`.
The main motivation is to ease threading through a `TyCtxt`.
(In hindsight it might have been better to instead attach the `TyCtxt`
to each of the different dataflow implementations, but that would
require e.g. switching away from having a `Default` impl, so I am
leaving that experiment for another time.)
2016-05-02 15:50:27 +02:00
|
|
|
{
|
|
|
|
each_child(move_path_index);
|
|
|
|
|
2019-06-03 18:26:48 -04:00
|
|
|
if is_terminal_path(tcx, body, move_data, move_path_index) {
|
Revised mir-dataflow.
Incorporates many fixes contributed by arielb1.
----
revise borrowck::mir::dataflow code to allow varying domain for bitvectors.
This particular code implements the `BitDenotation` trait for three
analyses:
* `MovingOutStatements`, which, like `borrowck::move_data`, maps each
bit-index to a move instruction, and a 1 means "the effect of this
move reaches this point" (and the assigned l-value, if a scoped
declaration, is still in scope).
* `MaybeInitializedLvals`, which maps each bit-index to an l-value.
A 1 means "there exists a control flow path to this point that
initializes the associated l-value."
* `MaybeUninitializedLvals`, which maps each bit-index to an l-value
A 1 means "there exists a control flow path to this point that
de-initializes the associated l-value."
----
Revised `graphviz` dataflow-rendering support in `borrowck::mir`.
One big difference is that this code is now parameterized over the
`BitDenotation`, so that it can be used to render dataflow results
independent of how the dataflow bitvectors are interpreted; see where
reference to `MoveOut` is replaced by the type parameter `D`.
----
Factor out routine to query subattributes in `#[rustc_mir(..)]`.
(Later commits build upon this for some unit testing and instrumentation.)
----
thread through a tcx so that I can query types of lvalues as part of analysis.
----
Revised `BitDenotation::Ctxt`, allowing variation beyond `MoveData`.
The main motivation is to ease threading through a `TyCtxt`.
(In hindsight it might have been better to instead attach the `TyCtxt`
to each of the different dataflow implementations, but that would
require e.g. switching away from having a `Default` impl, so I am
leaving that experiment for another time.)
2016-05-02 15:50:27 +02:00
|
|
|
return
|
|
|
|
}
|
|
|
|
|
|
|
|
let mut next_child_index = move_data.move_paths[move_path_index].first_child;
|
|
|
|
while let Some(child_index) = next_child_index {
|
2019-06-03 18:26:48 -04:00
|
|
|
on_all_children_bits(tcx, body, move_data, child_index, each_child);
|
Revised mir-dataflow.
Incorporates many fixes contributed by arielb1.
----
revise borrowck::mir::dataflow code to allow varying domain for bitvectors.
This particular code implements the `BitDenotation` trait for three
analyses:
* `MovingOutStatements`, which, like `borrowck::move_data`, maps each
bit-index to a move instruction, and a 1 means "the effect of this
move reaches this point" (and the assigned l-value, if a scoped
declaration, is still in scope).
* `MaybeInitializedLvals`, which maps each bit-index to an l-value.
A 1 means "there exists a control flow path to this point that
initializes the associated l-value."
* `MaybeUninitializedLvals`, which maps each bit-index to an l-value
A 1 means "there exists a control flow path to this point that
de-initializes the associated l-value."
----
Revised `graphviz` dataflow-rendering support in `borrowck::mir`.
One big difference is that this code is now parameterized over the
`BitDenotation`, so that it can be used to render dataflow results
independent of how the dataflow bitvectors are interpreted; see where
reference to `MoveOut` is replaced by the type parameter `D`.
----
Factor out routine to query subattributes in `#[rustc_mir(..)]`.
(Later commits build upon this for some unit testing and instrumentation.)
----
thread through a tcx so that I can query types of lvalues as part of analysis.
----
Revised `BitDenotation::Ctxt`, allowing variation beyond `MoveData`.
The main motivation is to ease threading through a `TyCtxt`.
(In hindsight it might have been better to instead attach the `TyCtxt`
to each of the different dataflow implementations, but that would
require e.g. switching away from having a `Default` impl, so I am
leaving that experiment for another time.)
2016-05-02 15:50:27 +02:00
|
|
|
next_child_index = move_data.move_paths[child_index].next_sibling;
|
|
|
|
}
|
|
|
|
}
|
2019-06-03 18:26:48 -04:00
|
|
|
on_all_children_bits(tcx, body, move_data, move_path_index, &mut each_child);
|
Revised mir-dataflow.
Incorporates many fixes contributed by arielb1.
----
revise borrowck::mir::dataflow code to allow varying domain for bitvectors.
This particular code implements the `BitDenotation` trait for three
analyses:
* `MovingOutStatements`, which, like `borrowck::move_data`, maps each
bit-index to a move instruction, and a 1 means "the effect of this
move reaches this point" (and the assigned l-value, if a scoped
declaration, is still in scope).
* `MaybeInitializedLvals`, which maps each bit-index to an l-value.
A 1 means "there exists a control flow path to this point that
initializes the associated l-value."
* `MaybeUninitializedLvals`, which maps each bit-index to an l-value
A 1 means "there exists a control flow path to this point that
de-initializes the associated l-value."
----
Revised `graphviz` dataflow-rendering support in `borrowck::mir`.
One big difference is that this code is now parameterized over the
`BitDenotation`, so that it can be used to render dataflow results
independent of how the dataflow bitvectors are interpreted; see where
reference to `MoveOut` is replaced by the type parameter `D`.
----
Factor out routine to query subattributes in `#[rustc_mir(..)]`.
(Later commits build upon this for some unit testing and instrumentation.)
----
thread through a tcx so that I can query types of lvalues as part of analysis.
----
Revised `BitDenotation::Ctxt`, allowing variation beyond `MoveData`.
The main motivation is to ease threading through a `TyCtxt`.
(In hindsight it might have been better to instead attach the `TyCtxt`
to each of the different dataflow implementations, but that would
require e.g. switching away from having a `Default` impl, so I am
leaving that experiment for another time.)
2016-05-02 15:50:27 +02:00
|
|
|
}
|
|
|
|
|
2019-06-14 00:48:52 +03:00
|
|
|
pub(crate) fn on_all_drop_children_bits<'tcx, F>(
|
|
|
|
tcx: TyCtxt<'tcx>,
|
2019-06-03 18:26:48 -04:00
|
|
|
body: &Body<'tcx>,
|
2019-06-14 00:48:52 +03:00
|
|
|
ctxt: &MoveDataParamEnv<'tcx>,
|
2017-04-07 01:00:53 +03:00
|
|
|
path: MovePathIndex,
|
2019-06-12 00:11:55 +03:00
|
|
|
mut each_child: F,
|
|
|
|
) where
|
|
|
|
F: FnMut(MovePathIndex),
|
2017-04-07 01:00:53 +03:00
|
|
|
{
|
2019-06-03 18:26:48 -04:00
|
|
|
on_all_children_bits(tcx, body, &ctxt.move_data, path, |child| {
|
2017-12-01 14:39:51 +02:00
|
|
|
let place = &ctxt.move_data.move_paths[path].place;
|
2019-06-03 18:26:48 -04:00
|
|
|
let ty = place.ty(body, tcx).ty;
|
2017-12-01 14:39:51 +02:00
|
|
|
debug!("on_all_drop_children_bits({:?}, {:?} : {:?})", path, place, ty);
|
2017-04-07 01:00:53 +03:00
|
|
|
|
2017-10-30 05:28:46 -04:00
|
|
|
let gcx = tcx.global_tcx();
|
2019-06-14 18:09:57 +02:00
|
|
|
let erased_ty = tcx.erase_regions(&ty);
|
2017-10-30 05:28:46 -04:00
|
|
|
if erased_ty.needs_drop(gcx, ctxt.param_env) {
|
2017-04-07 01:00:53 +03:00
|
|
|
each_child(child);
|
|
|
|
} else {
|
|
|
|
debug!("on_all_drop_children_bits - skipping")
|
|
|
|
}
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
2019-06-14 00:48:52 +03:00
|
|
|
pub(crate) fn drop_flag_effects_for_function_entry<'tcx, F>(
|
|
|
|
tcx: TyCtxt<'tcx>,
|
2019-06-03 18:26:48 -04:00
|
|
|
body: &Body<'tcx>,
|
2019-06-14 00:48:52 +03:00
|
|
|
ctxt: &MoveDataParamEnv<'tcx>,
|
2019-06-12 00:11:55 +03:00
|
|
|
mut callback: F,
|
|
|
|
) where
|
|
|
|
F: FnMut(MovePathIndex, DropFlagState),
|
Revised mir-dataflow.
Incorporates many fixes contributed by arielb1.
----
revise borrowck::mir::dataflow code to allow varying domain for bitvectors.
This particular code implements the `BitDenotation` trait for three
analyses:
* `MovingOutStatements`, which, like `borrowck::move_data`, maps each
bit-index to a move instruction, and a 1 means "the effect of this
move reaches this point" (and the assigned l-value, if a scoped
declaration, is still in scope).
* `MaybeInitializedLvals`, which maps each bit-index to an l-value.
A 1 means "there exists a control flow path to this point that
initializes the associated l-value."
* `MaybeUninitializedLvals`, which maps each bit-index to an l-value
A 1 means "there exists a control flow path to this point that
de-initializes the associated l-value."
----
Revised `graphviz` dataflow-rendering support in `borrowck::mir`.
One big difference is that this code is now parameterized over the
`BitDenotation`, so that it can be used to render dataflow results
independent of how the dataflow bitvectors are interpreted; see where
reference to `MoveOut` is replaced by the type parameter `D`.
----
Factor out routine to query subattributes in `#[rustc_mir(..)]`.
(Later commits build upon this for some unit testing and instrumentation.)
----
thread through a tcx so that I can query types of lvalues as part of analysis.
----
Revised `BitDenotation::Ctxt`, allowing variation beyond `MoveData`.
The main motivation is to ease threading through a `TyCtxt`.
(In hindsight it might have been better to instead attach the `TyCtxt`
to each of the different dataflow implementations, but that would
require e.g. switching away from having a `Default` impl, so I am
leaving that experiment for another time.)
2016-05-02 15:50:27 +02:00
|
|
|
{
|
2016-05-24 23:03:52 +02:00
|
|
|
let move_data = &ctxt.move_data;
|
2019-06-03 18:26:48 -04:00
|
|
|
for arg in body.args_iter() {
|
2019-06-24 17:46:09 +02:00
|
|
|
let place = mir::Place::from(arg);
|
2019-07-21 22:38:30 +02:00
|
|
|
let lookup_result = move_data.rev_lookup.find(place.as_ref());
|
2019-06-03 18:26:48 -04:00
|
|
|
on_lookup_result_bits(tcx, body, move_data,
|
2016-06-11 23:47:28 +03:00
|
|
|
lookup_result,
|
2017-08-09 22:23:27 +03:00
|
|
|
|mpi| callback(mpi, DropFlagState::Present));
|
Revised mir-dataflow.
Incorporates many fixes contributed by arielb1.
----
revise borrowck::mir::dataflow code to allow varying domain for bitvectors.
This particular code implements the `BitDenotation` trait for three
analyses:
* `MovingOutStatements`, which, like `borrowck::move_data`, maps each
bit-index to a move instruction, and a 1 means "the effect of this
move reaches this point" (and the assigned l-value, if a scoped
declaration, is still in scope).
* `MaybeInitializedLvals`, which maps each bit-index to an l-value.
A 1 means "there exists a control flow path to this point that
initializes the associated l-value."
* `MaybeUninitializedLvals`, which maps each bit-index to an l-value
A 1 means "there exists a control flow path to this point that
de-initializes the associated l-value."
----
Revised `graphviz` dataflow-rendering support in `borrowck::mir`.
One big difference is that this code is now parameterized over the
`BitDenotation`, so that it can be used to render dataflow results
independent of how the dataflow bitvectors are interpreted; see where
reference to `MoveOut` is replaced by the type parameter `D`.
----
Factor out routine to query subattributes in `#[rustc_mir(..)]`.
(Later commits build upon this for some unit testing and instrumentation.)
----
thread through a tcx so that I can query types of lvalues as part of analysis.
----
Revised `BitDenotation::Ctxt`, allowing variation beyond `MoveData`.
The main motivation is to ease threading through a `TyCtxt`.
(In hindsight it might have been better to instead attach the `TyCtxt`
to each of the different dataflow implementations, but that would
require e.g. switching away from having a `Default` impl, so I am
leaving that experiment for another time.)
2016-05-02 15:50:27 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-06-14 00:48:52 +03:00
|
|
|
pub(crate) fn drop_flag_effects_for_location<'tcx, F>(
|
|
|
|
tcx: TyCtxt<'tcx>,
|
2019-06-03 18:26:48 -04:00
|
|
|
body: &Body<'tcx>,
|
2019-06-14 00:48:52 +03:00
|
|
|
ctxt: &MoveDataParamEnv<'tcx>,
|
Revised mir-dataflow.
Incorporates many fixes contributed by arielb1.
----
revise borrowck::mir::dataflow code to allow varying domain for bitvectors.
This particular code implements the `BitDenotation` trait for three
analyses:
* `MovingOutStatements`, which, like `borrowck::move_data`, maps each
bit-index to a move instruction, and a 1 means "the effect of this
move reaches this point" (and the assigned l-value, if a scoped
declaration, is still in scope).
* `MaybeInitializedLvals`, which maps each bit-index to an l-value.
A 1 means "there exists a control flow path to this point that
initializes the associated l-value."
* `MaybeUninitializedLvals`, which maps each bit-index to an l-value
A 1 means "there exists a control flow path to this point that
de-initializes the associated l-value."
----
Revised `graphviz` dataflow-rendering support in `borrowck::mir`.
One big difference is that this code is now parameterized over the
`BitDenotation`, so that it can be used to render dataflow results
independent of how the dataflow bitvectors are interpreted; see where
reference to `MoveOut` is replaced by the type parameter `D`.
----
Factor out routine to query subattributes in `#[rustc_mir(..)]`.
(Later commits build upon this for some unit testing and instrumentation.)
----
thread through a tcx so that I can query types of lvalues as part of analysis.
----
Revised `BitDenotation::Ctxt`, allowing variation beyond `MoveData`.
The main motivation is to ease threading through a `TyCtxt`.
(In hindsight it might have been better to instead attach the `TyCtxt`
to each of the different dataflow implementations, but that would
require e.g. switching away from having a `Default` impl, so I am
leaving that experiment for another time.)
2016-05-02 15:50:27 +02:00
|
|
|
loc: Location,
|
2019-06-12 00:11:55 +03:00
|
|
|
mut callback: F,
|
|
|
|
) where
|
|
|
|
F: FnMut(MovePathIndex, DropFlagState),
|
Revised mir-dataflow.
Incorporates many fixes contributed by arielb1.
----
revise borrowck::mir::dataflow code to allow varying domain for bitvectors.
This particular code implements the `BitDenotation` trait for three
analyses:
* `MovingOutStatements`, which, like `borrowck::move_data`, maps each
bit-index to a move instruction, and a 1 means "the effect of this
move reaches this point" (and the assigned l-value, if a scoped
declaration, is still in scope).
* `MaybeInitializedLvals`, which maps each bit-index to an l-value.
A 1 means "there exists a control flow path to this point that
initializes the associated l-value."
* `MaybeUninitializedLvals`, which maps each bit-index to an l-value
A 1 means "there exists a control flow path to this point that
de-initializes the associated l-value."
----
Revised `graphviz` dataflow-rendering support in `borrowck::mir`.
One big difference is that this code is now parameterized over the
`BitDenotation`, so that it can be used to render dataflow results
independent of how the dataflow bitvectors are interpreted; see where
reference to `MoveOut` is replaced by the type parameter `D`.
----
Factor out routine to query subattributes in `#[rustc_mir(..)]`.
(Later commits build upon this for some unit testing and instrumentation.)
----
thread through a tcx so that I can query types of lvalues as part of analysis.
----
Revised `BitDenotation::Ctxt`, allowing variation beyond `MoveData`.
The main motivation is to ease threading through a `TyCtxt`.
(In hindsight it might have been better to instead attach the `TyCtxt`
to each of the different dataflow implementations, but that would
require e.g. switching away from having a `Default` impl, so I am
leaving that experiment for another time.)
2016-05-02 15:50:27 +02:00
|
|
|
{
|
2016-05-24 23:03:52 +02:00
|
|
|
let move_data = &ctxt.move_data;
|
Revised mir-dataflow.
Incorporates many fixes contributed by arielb1.
----
revise borrowck::mir::dataflow code to allow varying domain for bitvectors.
This particular code implements the `BitDenotation` trait for three
analyses:
* `MovingOutStatements`, which, like `borrowck::move_data`, maps each
bit-index to a move instruction, and a 1 means "the effect of this
move reaches this point" (and the assigned l-value, if a scoped
declaration, is still in scope).
* `MaybeInitializedLvals`, which maps each bit-index to an l-value.
A 1 means "there exists a control flow path to this point that
initializes the associated l-value."
* `MaybeUninitializedLvals`, which maps each bit-index to an l-value
A 1 means "there exists a control flow path to this point that
de-initializes the associated l-value."
----
Revised `graphviz` dataflow-rendering support in `borrowck::mir`.
One big difference is that this code is now parameterized over the
`BitDenotation`, so that it can be used to render dataflow results
independent of how the dataflow bitvectors are interpreted; see where
reference to `MoveOut` is replaced by the type parameter `D`.
----
Factor out routine to query subattributes in `#[rustc_mir(..)]`.
(Later commits build upon this for some unit testing and instrumentation.)
----
thread through a tcx so that I can query types of lvalues as part of analysis.
----
Revised `BitDenotation::Ctxt`, allowing variation beyond `MoveData`.
The main motivation is to ease threading through a `TyCtxt`.
(In hindsight it might have been better to instead attach the `TyCtxt`
to each of the different dataflow implementations, but that would
require e.g. switching away from having a `Default` impl, so I am
leaving that experiment for another time.)
2016-05-02 15:50:27 +02:00
|
|
|
debug!("drop_flag_effects_for_location({:?})", loc);
|
|
|
|
|
|
|
|
// first, move out of the RHS
|
|
|
|
for mi in &move_data.loc_map[loc] {
|
|
|
|
let path = mi.move_path_index(move_data);
|
|
|
|
debug!("moving out of path {:?}", move_data.move_paths[path]);
|
|
|
|
|
2019-06-03 18:26:48 -04:00
|
|
|
on_all_children_bits(tcx, body, move_data,
|
Revised mir-dataflow.
Incorporates many fixes contributed by arielb1.
----
revise borrowck::mir::dataflow code to allow varying domain for bitvectors.
This particular code implements the `BitDenotation` trait for three
analyses:
* `MovingOutStatements`, which, like `borrowck::move_data`, maps each
bit-index to a move instruction, and a 1 means "the effect of this
move reaches this point" (and the assigned l-value, if a scoped
declaration, is still in scope).
* `MaybeInitializedLvals`, which maps each bit-index to an l-value.
A 1 means "there exists a control flow path to this point that
initializes the associated l-value."
* `MaybeUninitializedLvals`, which maps each bit-index to an l-value
A 1 means "there exists a control flow path to this point that
de-initializes the associated l-value."
----
Revised `graphviz` dataflow-rendering support in `borrowck::mir`.
One big difference is that this code is now parameterized over the
`BitDenotation`, so that it can be used to render dataflow results
independent of how the dataflow bitvectors are interpreted; see where
reference to `MoveOut` is replaced by the type parameter `D`.
----
Factor out routine to query subattributes in `#[rustc_mir(..)]`.
(Later commits build upon this for some unit testing and instrumentation.)
----
thread through a tcx so that I can query types of lvalues as part of analysis.
----
Revised `BitDenotation::Ctxt`, allowing variation beyond `MoveData`.
The main motivation is to ease threading through a `TyCtxt`.
(In hindsight it might have been better to instead attach the `TyCtxt`
to each of the different dataflow implementations, but that would
require e.g. switching away from having a `Default` impl, so I am
leaving that experiment for another time.)
2016-05-02 15:50:27 +02:00
|
|
|
path,
|
2017-08-09 22:23:27 +03:00
|
|
|
|mpi| callback(mpi, DropFlagState::Absent))
|
Revised mir-dataflow.
Incorporates many fixes contributed by arielb1.
----
revise borrowck::mir::dataflow code to allow varying domain for bitvectors.
This particular code implements the `BitDenotation` trait for three
analyses:
* `MovingOutStatements`, which, like `borrowck::move_data`, maps each
bit-index to a move instruction, and a 1 means "the effect of this
move reaches this point" (and the assigned l-value, if a scoped
declaration, is still in scope).
* `MaybeInitializedLvals`, which maps each bit-index to an l-value.
A 1 means "there exists a control flow path to this point that
initializes the associated l-value."
* `MaybeUninitializedLvals`, which maps each bit-index to an l-value
A 1 means "there exists a control flow path to this point that
de-initializes the associated l-value."
----
Revised `graphviz` dataflow-rendering support in `borrowck::mir`.
One big difference is that this code is now parameterized over the
`BitDenotation`, so that it can be used to render dataflow results
independent of how the dataflow bitvectors are interpreted; see where
reference to `MoveOut` is replaced by the type parameter `D`.
----
Factor out routine to query subattributes in `#[rustc_mir(..)]`.
(Later commits build upon this for some unit testing and instrumentation.)
----
thread through a tcx so that I can query types of lvalues as part of analysis.
----
Revised `BitDenotation::Ctxt`, allowing variation beyond `MoveData`.
The main motivation is to ease threading through a `TyCtxt`.
(In hindsight it might have been better to instead attach the `TyCtxt`
to each of the different dataflow implementations, but that would
require e.g. switching away from having a `Default` impl, so I am
leaving that experiment for another time.)
2016-05-02 15:50:27 +02:00
|
|
|
}
|
|
|
|
|
2017-11-27 08:06:36 +00:00
|
|
|
debug!("drop_flag_effects: assignment for location({:?})", loc);
|
|
|
|
|
|
|
|
for_location_inits(
|
|
|
|
tcx,
|
2019-06-03 18:26:48 -04:00
|
|
|
body,
|
2017-11-27 08:06:36 +00:00
|
|
|
move_data,
|
|
|
|
loc,
|
|
|
|
|mpi| callback(mpi, DropFlagState::Present)
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
2019-06-14 00:48:52 +03:00
|
|
|
pub(crate) fn for_location_inits<'tcx, F>(
|
|
|
|
tcx: TyCtxt<'tcx>,
|
2019-06-03 18:26:48 -04:00
|
|
|
body: &Body<'tcx>,
|
2017-11-27 08:06:36 +00:00
|
|
|
move_data: &MoveData<'tcx>,
|
|
|
|
loc: Location,
|
2019-06-12 00:11:55 +03:00
|
|
|
mut callback: F,
|
|
|
|
) where
|
|
|
|
F: FnMut(MovePathIndex),
|
2017-11-27 08:06:36 +00:00
|
|
|
{
|
|
|
|
for ii in &move_data.init_loc_map[loc] {
|
|
|
|
let init = move_data.inits[*ii];
|
|
|
|
match init.kind {
|
|
|
|
InitKind::Deep => {
|
|
|
|
let path = init.path;
|
|
|
|
|
2019-06-03 18:26:48 -04:00
|
|
|
on_all_children_bits(tcx, body, move_data,
|
2017-11-27 08:06:36 +00:00
|
|
|
path,
|
|
|
|
&mut callback)
|
|
|
|
},
|
|
|
|
InitKind::Shallow => {
|
|
|
|
let mpi = init.path;
|
|
|
|
callback(mpi);
|
2016-05-17 01:06:52 +03:00
|
|
|
}
|
2017-11-27 08:06:36 +00:00
|
|
|
InitKind::NonPanicPathOnly => (),
|
Revised mir-dataflow.
Incorporates many fixes contributed by arielb1.
----
revise borrowck::mir::dataflow code to allow varying domain for bitvectors.
This particular code implements the `BitDenotation` trait for three
analyses:
* `MovingOutStatements`, which, like `borrowck::move_data`, maps each
bit-index to a move instruction, and a 1 means "the effect of this
move reaches this point" (and the assigned l-value, if a scoped
declaration, is still in scope).
* `MaybeInitializedLvals`, which maps each bit-index to an l-value.
A 1 means "there exists a control flow path to this point that
initializes the associated l-value."
* `MaybeUninitializedLvals`, which maps each bit-index to an l-value
A 1 means "there exists a control flow path to this point that
de-initializes the associated l-value."
----
Revised `graphviz` dataflow-rendering support in `borrowck::mir`.
One big difference is that this code is now parameterized over the
`BitDenotation`, so that it can be used to render dataflow results
independent of how the dataflow bitvectors are interpreted; see where
reference to `MoveOut` is replaced by the type parameter `D`.
----
Factor out routine to query subattributes in `#[rustc_mir(..)]`.
(Later commits build upon this for some unit testing and instrumentation.)
----
thread through a tcx so that I can query types of lvalues as part of analysis.
----
Revised `BitDenotation::Ctxt`, allowing variation beyond `MoveData`.
The main motivation is to ease threading through a `TyCtxt`.
(In hindsight it might have been better to instead attach the `TyCtxt`
to each of the different dataflow implementations, but that would
require e.g. switching away from having a `Default` impl, so I am
leaving that experiment for another time.)
2016-05-02 15:50:27 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|