2017-07-03 18:40:20 +02:00
|
|
|
// Copyright 2012-2017 The Rust Project Developers. See the COPYRIGHT
|
|
|
|
// file at the top-level directory of this distribution and at
|
|
|
|
// http://rust-lang.org/COPYRIGHT.
|
|
|
|
//
|
|
|
|
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
|
|
|
|
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
|
|
|
|
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
|
|
|
|
// option. This file may not be copied, modified, or distributed
|
|
|
|
// except according to those terms.
|
|
|
|
|
2017-12-15 14:27:06 -06:00
|
|
|
use rustc;
|
2017-12-04 00:56:06 +02:00
|
|
|
use rustc::hir;
|
|
|
|
use rustc::hir::def_id::DefId;
|
|
|
|
use rustc::middle::region;
|
New `ActiveBorrows` dataflow for two-phase `&mut`; not yet borrowed-checked.
High-level picture: The old `Borrows` analysis is now called
`Reservations` (implemented as a newtype wrapper around `Borrows`);
this continues to compute whether a `Rvalue::Ref` can reach a
statement without an intervening `EndRegion`. In addition, we also
track what `Place` each such `Rvalue::Ref` was immediately assigned
to in a given borrow (yay for MIR-structural properties!).
The new `ActiveBorrows` analysis then tracks the initial use of any of
those assigned `Places` for a given borrow. I.e. a borrow becomes
"active" immediately after it starts being "used" in some way. (This
is conservative in the sense that we will treat a copy `x = y;` as a
use of `y`; in principle one might further delay activation in such
cases.)
The new `ActiveBorrows` analysis needs to take the `Reservations`
results as an initial input, because the reservation state influences
the gen/kill sets for `ActiveBorrows`. In particular, a use of `a`
activates a borrow `a = &b` if and only if there exists a path (in the
control flow graph) from the borrow to that use. So we need to know if
the borrow reaches a given use to know if it really gets a gen-bit or
not.
* Incorporating the output from one dataflow analysis into the input
of another required more changes to the infrastructure than I had
expected, and even after those changes, the resulting code is still
a bit subtle.
* In particular, Since we need to know the intrablock reservation
state, we need to dynamically update a bitvector for the
reservations as we are also trying to compute the gen/kills
bitvector for the active borrows.
* The way I ended up deciding to do this (after also toying with at
least two other designs) is to put both the reservation state and
the active borrow state into a single bitvector. That is why we now
have separate (but related) `BorrowIndex` and
`ReserveOrActivateIndex`: each borrow index maps to a pair of
neighboring reservation and activation indexes.
As noted above, these changes are solely adding the active borrows
dataflow analysis (and updating the existing code to cope with the
switch from `Borrows` to `Reservations`). The code to process the
bitvector in the borrow checker currently just skips over all of the
active borrow bits.
But atop this commit, one *can* observe the analysis results by
looking at the graphviz output, e.g. via
```rust
#[rustc_mir(borrowck_graphviz_preflow="pre_two_phase.dot",
borrowck_graphviz_postflow="post_two_phase.dot")]
```
Includes doc for `FindPlaceUses`, as well as `Reservations` and
`ActiveBorrows` structs, which are wrappers are the `Borrows` struct
that dictate which flow analysis should be performed.
2017-12-01 12:32:51 +01:00
|
|
|
use rustc::mir::{self, Location, Place, Mir};
|
2018-04-06 11:50:17 -04:00
|
|
|
use rustc::mir::traversal;
|
New `ActiveBorrows` dataflow for two-phase `&mut`; not yet borrowed-checked.
High-level picture: The old `Borrows` analysis is now called
`Reservations` (implemented as a newtype wrapper around `Borrows`);
this continues to compute whether a `Rvalue::Ref` can reach a
statement without an intervening `EndRegion`. In addition, we also
track what `Place` each such `Rvalue::Ref` was immediately assigned
to in a given borrow (yay for MIR-structural properties!).
The new `ActiveBorrows` analysis then tracks the initial use of any of
those assigned `Places` for a given borrow. I.e. a borrow becomes
"active" immediately after it starts being "used" in some way. (This
is conservative in the sense that we will treat a copy `x = y;` as a
use of `y`; in principle one might further delay activation in such
cases.)
The new `ActiveBorrows` analysis needs to take the `Reservations`
results as an initial input, because the reservation state influences
the gen/kill sets for `ActiveBorrows`. In particular, a use of `a`
activates a borrow `a = &b` if and only if there exists a path (in the
control flow graph) from the borrow to that use. So we need to know if
the borrow reaches a given use to know if it really gets a gen-bit or
not.
* Incorporating the output from one dataflow analysis into the input
of another required more changes to the infrastructure than I had
expected, and even after those changes, the resulting code is still
a bit subtle.
* In particular, Since we need to know the intrablock reservation
state, we need to dynamically update a bitvector for the
reservations as we are also trying to compute the gen/kills
bitvector for the active borrows.
* The way I ended up deciding to do this (after also toying with at
least two other designs) is to put both the reservation state and
the active borrow state into a single bitvector. That is why we now
have separate (but related) `BorrowIndex` and
`ReserveOrActivateIndex`: each borrow index maps to a pair of
neighboring reservation and activation indexes.
As noted above, these changes are solely adding the active borrows
dataflow analysis (and updating the existing code to cope with the
switch from `Borrows` to `Reservations`). The code to process the
bitvector in the borrow checker currently just skips over all of the
active borrow bits.
But atop this commit, one *can* observe the analysis results by
looking at the graphviz output, e.g. via
```rust
#[rustc_mir(borrowck_graphviz_preflow="pre_two_phase.dot",
borrowck_graphviz_postflow="post_two_phase.dot")]
```
Includes doc for `FindPlaceUses`, as well as `Reservations` and
`ActiveBorrows` structs, which are wrappers are the `Borrows` struct
that dictate which flow analysis should be performed.
2017-12-01 12:32:51 +01:00
|
|
|
use rustc::mir::visit::{PlaceContext, Visitor};
|
2017-11-16 15:32:13 -08:00
|
|
|
use rustc::ty::{self, Region, TyCtxt};
|
2017-09-27 10:01:42 +03:00
|
|
|
use rustc::ty::RegionKind;
|
2017-07-03 18:40:20 +02:00
|
|
|
use rustc::ty::RegionKind::ReScope;
|
|
|
|
use rustc::util::nodemap::{FxHashMap, FxHashSet};
|
|
|
|
|
|
|
|
use rustc_data_structures::bitslice::{BitwiseOperator};
|
|
|
|
use rustc_data_structures::indexed_set::{IdxSet};
|
New `ActiveBorrows` dataflow for two-phase `&mut`; not yet borrowed-checked.
High-level picture: The old `Borrows` analysis is now called
`Reservations` (implemented as a newtype wrapper around `Borrows`);
this continues to compute whether a `Rvalue::Ref` can reach a
statement without an intervening `EndRegion`. In addition, we also
track what `Place` each such `Rvalue::Ref` was immediately assigned
to in a given borrow (yay for MIR-structural properties!).
The new `ActiveBorrows` analysis then tracks the initial use of any of
those assigned `Places` for a given borrow. I.e. a borrow becomes
"active" immediately after it starts being "used" in some way. (This
is conservative in the sense that we will treat a copy `x = y;` as a
use of `y`; in principle one might further delay activation in such
cases.)
The new `ActiveBorrows` analysis needs to take the `Reservations`
results as an initial input, because the reservation state influences
the gen/kill sets for `ActiveBorrows`. In particular, a use of `a`
activates a borrow `a = &b` if and only if there exists a path (in the
control flow graph) from the borrow to that use. So we need to know if
the borrow reaches a given use to know if it really gets a gen-bit or
not.
* Incorporating the output from one dataflow analysis into the input
of another required more changes to the infrastructure than I had
expected, and even after those changes, the resulting code is still
a bit subtle.
* In particular, Since we need to know the intrablock reservation
state, we need to dynamically update a bitvector for the
reservations as we are also trying to compute the gen/kills
bitvector for the active borrows.
* The way I ended up deciding to do this (after also toying with at
least two other designs) is to put both the reservation state and
the active borrow state into a single bitvector. That is why we now
have separate (but related) `BorrowIndex` and
`ReserveOrActivateIndex`: each borrow index maps to a pair of
neighboring reservation and activation indexes.
As noted above, these changes are solely adding the active borrows
dataflow analysis (and updating the existing code to cope with the
switch from `Borrows` to `Reservations`). The code to process the
bitvector in the borrow checker currently just skips over all of the
active borrow bits.
But atop this commit, one *can* observe the analysis results by
looking at the graphviz output, e.g. via
```rust
#[rustc_mir(borrowck_graphviz_preflow="pre_two_phase.dot",
borrowck_graphviz_postflow="post_two_phase.dot")]
```
Includes doc for `FindPlaceUses`, as well as `Reservations` and
`ActiveBorrows` structs, which are wrappers are the `Borrows` struct
that dictate which flow analysis should be performed.
2017-12-01 12:32:51 +01:00
|
|
|
use rustc_data_structures::indexed_vec::{Idx, IndexVec};
|
2018-02-27 17:11:14 +01:00
|
|
|
use rustc_data_structures::sync::Lrc;
|
2017-07-03 18:40:20 +02:00
|
|
|
|
2017-11-27 15:08:11 +01:00
|
|
|
use dataflow::{BitDenotation, BlockSets, InitialFlow};
|
New `ActiveBorrows` dataflow for two-phase `&mut`; not yet borrowed-checked.
High-level picture: The old `Borrows` analysis is now called
`Reservations` (implemented as a newtype wrapper around `Borrows`);
this continues to compute whether a `Rvalue::Ref` can reach a
statement without an intervening `EndRegion`. In addition, we also
track what `Place` each such `Rvalue::Ref` was immediately assigned
to in a given borrow (yay for MIR-structural properties!).
The new `ActiveBorrows` analysis then tracks the initial use of any of
those assigned `Places` for a given borrow. I.e. a borrow becomes
"active" immediately after it starts being "used" in some way. (This
is conservative in the sense that we will treat a copy `x = y;` as a
use of `y`; in principle one might further delay activation in such
cases.)
The new `ActiveBorrows` analysis needs to take the `Reservations`
results as an initial input, because the reservation state influences
the gen/kill sets for `ActiveBorrows`. In particular, a use of `a`
activates a borrow `a = &b` if and only if there exists a path (in the
control flow graph) from the borrow to that use. So we need to know if
the borrow reaches a given use to know if it really gets a gen-bit or
not.
* Incorporating the output from one dataflow analysis into the input
of another required more changes to the infrastructure than I had
expected, and even after those changes, the resulting code is still
a bit subtle.
* In particular, Since we need to know the intrablock reservation
state, we need to dynamically update a bitvector for the
reservations as we are also trying to compute the gen/kills
bitvector for the active borrows.
* The way I ended up deciding to do this (after also toying with at
least two other designs) is to put both the reservation state and
the active borrow state into a single bitvector. That is why we now
have separate (but related) `BorrowIndex` and
`ReserveOrActivateIndex`: each borrow index maps to a pair of
neighboring reservation and activation indexes.
As noted above, these changes are solely adding the active borrows
dataflow analysis (and updating the existing code to cope with the
switch from `Borrows` to `Reservations`). The code to process the
bitvector in the borrow checker currently just skips over all of the
active borrow bits.
But atop this commit, one *can* observe the analysis results by
looking at the graphviz output, e.g. via
```rust
#[rustc_mir(borrowck_graphviz_preflow="pre_two_phase.dot",
borrowck_graphviz_postflow="post_two_phase.dot")]
```
Includes doc for `FindPlaceUses`, as well as `Reservations` and
`ActiveBorrows` structs, which are wrappers are the `Borrows` struct
that dictate which flow analysis should be performed.
2017-12-01 12:32:51 +01:00
|
|
|
pub use dataflow::indexes::{BorrowIndex, ReserveOrActivateIndex};
|
2017-11-17 04:34:02 -05:00
|
|
|
use borrow_check::nll::region_infer::RegionInferenceContext;
|
|
|
|
use borrow_check::nll::ToRegionVid;
|
2017-07-03 18:40:20 +02:00
|
|
|
|
2017-09-27 10:01:42 +03:00
|
|
|
use syntax_pos::Span;
|
|
|
|
|
2017-07-03 18:40:20 +02:00
|
|
|
use std::fmt;
|
New `ActiveBorrows` dataflow for two-phase `&mut`; not yet borrowed-checked.
High-level picture: The old `Borrows` analysis is now called
`Reservations` (implemented as a newtype wrapper around `Borrows`);
this continues to compute whether a `Rvalue::Ref` can reach a
statement without an intervening `EndRegion`. In addition, we also
track what `Place` each such `Rvalue::Ref` was immediately assigned
to in a given borrow (yay for MIR-structural properties!).
The new `ActiveBorrows` analysis then tracks the initial use of any of
those assigned `Places` for a given borrow. I.e. a borrow becomes
"active" immediately after it starts being "used" in some way. (This
is conservative in the sense that we will treat a copy `x = y;` as a
use of `y`; in principle one might further delay activation in such
cases.)
The new `ActiveBorrows` analysis needs to take the `Reservations`
results as an initial input, because the reservation state influences
the gen/kill sets for `ActiveBorrows`. In particular, a use of `a`
activates a borrow `a = &b` if and only if there exists a path (in the
control flow graph) from the borrow to that use. So we need to know if
the borrow reaches a given use to know if it really gets a gen-bit or
not.
* Incorporating the output from one dataflow analysis into the input
of another required more changes to the infrastructure than I had
expected, and even after those changes, the resulting code is still
a bit subtle.
* In particular, Since we need to know the intrablock reservation
state, we need to dynamically update a bitvector for the
reservations as we are also trying to compute the gen/kills
bitvector for the active borrows.
* The way I ended up deciding to do this (after also toying with at
least two other designs) is to put both the reservation state and
the active borrow state into a single bitvector. That is why we now
have separate (but related) `BorrowIndex` and
`ReserveOrActivateIndex`: each borrow index maps to a pair of
neighboring reservation and activation indexes.
As noted above, these changes are solely adding the active borrows
dataflow analysis (and updating the existing code to cope with the
switch from `Borrows` to `Reservations`). The code to process the
bitvector in the borrow checker currently just skips over all of the
active borrow bits.
But atop this commit, one *can* observe the analysis results by
looking at the graphviz output, e.g. via
```rust
#[rustc_mir(borrowck_graphviz_preflow="pre_two_phase.dot",
borrowck_graphviz_postflow="post_two_phase.dot")]
```
Includes doc for `FindPlaceUses`, as well as `Reservations` and
`ActiveBorrows` structs, which are wrappers are the `Borrows` struct
that dictate which flow analysis should be performed.
2017-12-01 12:32:51 +01:00
|
|
|
use std::hash::Hash;
|
2017-12-04 00:56:06 +02:00
|
|
|
use std::rc::Rc;
|
2017-07-03 18:40:20 +02:00
|
|
|
|
2017-12-13 01:06:39 -06:00
|
|
|
/// `Borrows` stores the data used in the analyses that track the flow
|
|
|
|
/// of borrows.
|
|
|
|
///
|
|
|
|
/// It uniquely identifies every borrow (`Rvalue::Ref`) by a
|
|
|
|
/// `BorrowIndex`, and maps each such index to a `BorrowData`
|
|
|
|
/// describing the borrow. These indexes are used for representing the
|
|
|
|
/// borrows in compact bitvectors.
|
2017-10-30 05:50:39 -04:00
|
|
|
pub struct Borrows<'a, 'gcx: 'tcx, 'tcx: 'a> {
|
|
|
|
tcx: TyCtxt<'a, 'gcx, 'tcx>,
|
2017-07-03 18:40:20 +02:00
|
|
|
mir: &'a Mir<'tcx>,
|
2018-02-27 17:11:14 +01:00
|
|
|
scope_tree: Lrc<region::ScopeTree>,
|
2017-12-04 00:56:06 +02:00
|
|
|
root_scope: Option<region::Scope>,
|
2017-12-13 01:06:39 -06:00
|
|
|
|
|
|
|
/// The fundamental map relating bitvector indexes to the borrows
|
|
|
|
/// in the MIR.
|
2017-07-03 18:40:20 +02:00
|
|
|
borrows: IndexVec<BorrowIndex, BorrowData<'tcx>>,
|
2017-12-13 01:06:39 -06:00
|
|
|
|
|
|
|
/// Each borrow is also uniquely identified in the MIR by the
|
|
|
|
/// `Location` of the assignment statement in which it appears on
|
|
|
|
/// the right hand side; we map each such location to the
|
|
|
|
/// corresponding `BorrowIndex`.
|
2017-07-03 18:40:20 +02:00
|
|
|
location_map: FxHashMap<Location, BorrowIndex>,
|
2017-12-13 01:06:39 -06:00
|
|
|
|
2018-03-05 02:44:10 -05:00
|
|
|
/// Locations which activate borrows.
|
2018-04-04 23:08:10 -04:00
|
|
|
activation_map: FxHashMap<Location, FxHashSet<BorrowIndex>>,
|
2018-03-05 02:44:10 -05:00
|
|
|
|
2017-12-13 01:06:39 -06:00
|
|
|
/// Every borrow has a region; this maps each such regions back to
|
|
|
|
/// its borrow-indexes.
|
2017-07-03 18:40:20 +02:00
|
|
|
region_map: FxHashMap<Region<'tcx>, FxHashSet<BorrowIndex>>,
|
2018-03-05 02:44:10 -05:00
|
|
|
|
|
|
|
/// Map from local to all the borrows on that local
|
2017-12-04 13:21:28 +02:00
|
|
|
local_map: FxHashMap<mir::Local, FxHashSet<BorrowIndex>>,
|
2017-07-03 18:40:20 +02:00
|
|
|
|
2018-03-05 02:44:10 -05:00
|
|
|
/// Maps regions to their corresponding source spans
|
|
|
|
/// Only contains ReScope()s as keys
|
|
|
|
region_span_map: FxHashMap<RegionKind, Span>,
|
New `ActiveBorrows` dataflow for two-phase `&mut`; not yet borrowed-checked.
High-level picture: The old `Borrows` analysis is now called
`Reservations` (implemented as a newtype wrapper around `Borrows`);
this continues to compute whether a `Rvalue::Ref` can reach a
statement without an intervening `EndRegion`. In addition, we also
track what `Place` each such `Rvalue::Ref` was immediately assigned
to in a given borrow (yay for MIR-structural properties!).
The new `ActiveBorrows` analysis then tracks the initial use of any of
those assigned `Places` for a given borrow. I.e. a borrow becomes
"active" immediately after it starts being "used" in some way. (This
is conservative in the sense that we will treat a copy `x = y;` as a
use of `y`; in principle one might further delay activation in such
cases.)
The new `ActiveBorrows` analysis needs to take the `Reservations`
results as an initial input, because the reservation state influences
the gen/kill sets for `ActiveBorrows`. In particular, a use of `a`
activates a borrow `a = &b` if and only if there exists a path (in the
control flow graph) from the borrow to that use. So we need to know if
the borrow reaches a given use to know if it really gets a gen-bit or
not.
* Incorporating the output from one dataflow analysis into the input
of another required more changes to the infrastructure than I had
expected, and even after those changes, the resulting code is still
a bit subtle.
* In particular, Since we need to know the intrablock reservation
state, we need to dynamically update a bitvector for the
reservations as we are also trying to compute the gen/kills
bitvector for the active borrows.
* The way I ended up deciding to do this (after also toying with at
least two other designs) is to put both the reservation state and
the active borrow state into a single bitvector. That is why we now
have separate (but related) `BorrowIndex` and
`ReserveOrActivateIndex`: each borrow index maps to a pair of
neighboring reservation and activation indexes.
As noted above, these changes are solely adding the active borrows
dataflow analysis (and updating the existing code to cope with the
switch from `Borrows` to `Reservations`). The code to process the
bitvector in the borrow checker currently just skips over all of the
active borrow bits.
But atop this commit, one *can* observe the analysis results by
looking at the graphviz output, e.g. via
```rust
#[rustc_mir(borrowck_graphviz_preflow="pre_two_phase.dot",
borrowck_graphviz_postflow="post_two_phase.dot")]
```
Includes doc for `FindPlaceUses`, as well as `Reservations` and
`ActiveBorrows` structs, which are wrappers are the `Borrows` struct
that dictate which flow analysis should be performed.
2017-12-01 12:32:51 +01:00
|
|
|
|
2018-03-05 02:44:10 -05:00
|
|
|
/// NLL region inference context with which NLL queries should be resolved
|
|
|
|
nonlexical_regioncx: Option<Rc<RegionInferenceContext<'tcx>>>,
|
New `ActiveBorrows` dataflow for two-phase `&mut`; not yet borrowed-checked.
High-level picture: The old `Borrows` analysis is now called
`Reservations` (implemented as a newtype wrapper around `Borrows`);
this continues to compute whether a `Rvalue::Ref` can reach a
statement without an intervening `EndRegion`. In addition, we also
track what `Place` each such `Rvalue::Ref` was immediately assigned
to in a given borrow (yay for MIR-structural properties!).
The new `ActiveBorrows` analysis then tracks the initial use of any of
those assigned `Places` for a given borrow. I.e. a borrow becomes
"active" immediately after it starts being "used" in some way. (This
is conservative in the sense that we will treat a copy `x = y;` as a
use of `y`; in principle one might further delay activation in such
cases.)
The new `ActiveBorrows` analysis needs to take the `Reservations`
results as an initial input, because the reservation state influences
the gen/kill sets for `ActiveBorrows`. In particular, a use of `a`
activates a borrow `a = &b` if and only if there exists a path (in the
control flow graph) from the borrow to that use. So we need to know if
the borrow reaches a given use to know if it really gets a gen-bit or
not.
* Incorporating the output from one dataflow analysis into the input
of another required more changes to the infrastructure than I had
expected, and even after those changes, the resulting code is still
a bit subtle.
* In particular, Since we need to know the intrablock reservation
state, we need to dynamically update a bitvector for the
reservations as we are also trying to compute the gen/kills
bitvector for the active borrows.
* The way I ended up deciding to do this (after also toying with at
least two other designs) is to put both the reservation state and
the active borrow state into a single bitvector. That is why we now
have separate (but related) `BorrowIndex` and
`ReserveOrActivateIndex`: each borrow index maps to a pair of
neighboring reservation and activation indexes.
As noted above, these changes are solely adding the active borrows
dataflow analysis (and updating the existing code to cope with the
switch from `Borrows` to `Reservations`). The code to process the
bitvector in the borrow checker currently just skips over all of the
active borrow bits.
But atop this commit, one *can* observe the analysis results by
looking at the graphviz output, e.g. via
```rust
#[rustc_mir(borrowck_graphviz_preflow="pre_two_phase.dot",
borrowck_graphviz_postflow="post_two_phase.dot")]
```
Includes doc for `FindPlaceUses`, as well as `Reservations` and
`ActiveBorrows` structs, which are wrappers are the `Borrows` struct
that dictate which flow analysis should be performed.
2017-12-01 12:32:51 +01:00
|
|
|
}
|
|
|
|
|
2017-07-03 18:40:20 +02:00
|
|
|
// temporarily allow some dead fields: `kind` and `region` will be
|
2017-11-28 12:49:06 +01:00
|
|
|
// needed by borrowck; `borrowed_place` will probably be a MovePathIndex when
|
2017-07-03 18:40:20 +02:00
|
|
|
// that is extended to include borrowed data paths.
|
|
|
|
#[allow(dead_code)]
|
|
|
|
#[derive(Debug)]
|
|
|
|
pub struct BorrowData<'tcx> {
|
2018-03-04 21:47:39 -05:00
|
|
|
/// Location where the borrow reservation starts.
|
|
|
|
/// In many cases, this will be equal to the activation location but not always.
|
|
|
|
pub(crate) reserve_location: Location,
|
2018-04-06 11:50:17 -04:00
|
|
|
/// Location where the borrow is activated. None if this is not a
|
|
|
|
/// 2-phase borrow.
|
|
|
|
pub(crate) activation_location: Option<Location>,
|
2018-03-05 02:44:10 -05:00
|
|
|
/// What kind of borrow this is
|
2017-07-03 18:40:20 +02:00
|
|
|
pub(crate) kind: mir::BorrowKind,
|
2018-03-05 02:44:10 -05:00
|
|
|
/// The region for which this borrow is live
|
2017-07-03 18:40:20 +02:00
|
|
|
pub(crate) region: Region<'tcx>,
|
2018-03-05 02:44:10 -05:00
|
|
|
/// Place from which we are borrowing
|
2017-11-28 12:49:06 +01:00
|
|
|
pub(crate) borrowed_place: mir::Place<'tcx>,
|
2018-03-05 02:44:10 -05:00
|
|
|
/// Place to which the borrow was stored
|
New `ActiveBorrows` dataflow for two-phase `&mut`; not yet borrowed-checked.
High-level picture: The old `Borrows` analysis is now called
`Reservations` (implemented as a newtype wrapper around `Borrows`);
this continues to compute whether a `Rvalue::Ref` can reach a
statement without an intervening `EndRegion`. In addition, we also
track what `Place` each such `Rvalue::Ref` was immediately assigned
to in a given borrow (yay for MIR-structural properties!).
The new `ActiveBorrows` analysis then tracks the initial use of any of
those assigned `Places` for a given borrow. I.e. a borrow becomes
"active" immediately after it starts being "used" in some way. (This
is conservative in the sense that we will treat a copy `x = y;` as a
use of `y`; in principle one might further delay activation in such
cases.)
The new `ActiveBorrows` analysis needs to take the `Reservations`
results as an initial input, because the reservation state influences
the gen/kill sets for `ActiveBorrows`. In particular, a use of `a`
activates a borrow `a = &b` if and only if there exists a path (in the
control flow graph) from the borrow to that use. So we need to know if
the borrow reaches a given use to know if it really gets a gen-bit or
not.
* Incorporating the output from one dataflow analysis into the input
of another required more changes to the infrastructure than I had
expected, and even after those changes, the resulting code is still
a bit subtle.
* In particular, Since we need to know the intrablock reservation
state, we need to dynamically update a bitvector for the
reservations as we are also trying to compute the gen/kills
bitvector for the active borrows.
* The way I ended up deciding to do this (after also toying with at
least two other designs) is to put both the reservation state and
the active borrow state into a single bitvector. That is why we now
have separate (but related) `BorrowIndex` and
`ReserveOrActivateIndex`: each borrow index maps to a pair of
neighboring reservation and activation indexes.
As noted above, these changes are solely adding the active borrows
dataflow analysis (and updating the existing code to cope with the
switch from `Borrows` to `Reservations`). The code to process the
bitvector in the borrow checker currently just skips over all of the
active borrow bits.
But atop this commit, one *can* observe the analysis results by
looking at the graphviz output, e.g. via
```rust
#[rustc_mir(borrowck_graphviz_preflow="pre_two_phase.dot",
borrowck_graphviz_postflow="post_two_phase.dot")]
```
Includes doc for `FindPlaceUses`, as well as `Reservations` and
`ActiveBorrows` structs, which are wrappers are the `Borrows` struct
that dictate which flow analysis should be performed.
2017-12-01 12:32:51 +01:00
|
|
|
pub(crate) assigned_place: mir::Place<'tcx>,
|
2017-07-03 18:40:20 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
impl<'tcx> fmt::Display for BorrowData<'tcx> {
|
|
|
|
fn fmt(&self, w: &mut fmt::Formatter) -> fmt::Result {
|
|
|
|
let kind = match self.kind {
|
|
|
|
mir::BorrowKind::Shared => "",
|
|
|
|
mir::BorrowKind::Unique => "uniq ",
|
2018-01-15 12:47:26 +01:00
|
|
|
mir::BorrowKind::Mut { .. } => "mut ",
|
2017-07-03 18:40:20 +02:00
|
|
|
};
|
|
|
|
let region = format!("{}", self.region);
|
|
|
|
let region = if region.len() > 0 { format!("{} ", region) } else { region };
|
2017-11-28 12:49:06 +01:00
|
|
|
write!(w, "&{}{}{:?}", region, kind, self.borrowed_place)
|
2017-07-03 18:40:20 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
New `ActiveBorrows` dataflow for two-phase `&mut`; not yet borrowed-checked.
High-level picture: The old `Borrows` analysis is now called
`Reservations` (implemented as a newtype wrapper around `Borrows`);
this continues to compute whether a `Rvalue::Ref` can reach a
statement without an intervening `EndRegion`. In addition, we also
track what `Place` each such `Rvalue::Ref` was immediately assigned
to in a given borrow (yay for MIR-structural properties!).
The new `ActiveBorrows` analysis then tracks the initial use of any of
those assigned `Places` for a given borrow. I.e. a borrow becomes
"active" immediately after it starts being "used" in some way. (This
is conservative in the sense that we will treat a copy `x = y;` as a
use of `y`; in principle one might further delay activation in such
cases.)
The new `ActiveBorrows` analysis needs to take the `Reservations`
results as an initial input, because the reservation state influences
the gen/kill sets for `ActiveBorrows`. In particular, a use of `a`
activates a borrow `a = &b` if and only if there exists a path (in the
control flow graph) from the borrow to that use. So we need to know if
the borrow reaches a given use to know if it really gets a gen-bit or
not.
* Incorporating the output from one dataflow analysis into the input
of another required more changes to the infrastructure than I had
expected, and even after those changes, the resulting code is still
a bit subtle.
* In particular, Since we need to know the intrablock reservation
state, we need to dynamically update a bitvector for the
reservations as we are also trying to compute the gen/kills
bitvector for the active borrows.
* The way I ended up deciding to do this (after also toying with at
least two other designs) is to put both the reservation state and
the active borrow state into a single bitvector. That is why we now
have separate (but related) `BorrowIndex` and
`ReserveOrActivateIndex`: each borrow index maps to a pair of
neighboring reservation and activation indexes.
As noted above, these changes are solely adding the active borrows
dataflow analysis (and updating the existing code to cope with the
switch from `Borrows` to `Reservations`). The code to process the
bitvector in the borrow checker currently just skips over all of the
active borrow bits.
But atop this commit, one *can* observe the analysis results by
looking at the graphviz output, e.g. via
```rust
#[rustc_mir(borrowck_graphviz_preflow="pre_two_phase.dot",
borrowck_graphviz_postflow="post_two_phase.dot")]
```
Includes doc for `FindPlaceUses`, as well as `Reservations` and
`ActiveBorrows` structs, which are wrappers are the `Borrows` struct
that dictate which flow analysis should be performed.
2017-12-01 12:32:51 +01:00
|
|
|
impl ReserveOrActivateIndex {
|
2017-12-23 19:28:33 -08:00
|
|
|
fn reserved(i: BorrowIndex) -> Self { ReserveOrActivateIndex::new(i.index() * 2) }
|
New `ActiveBorrows` dataflow for two-phase `&mut`; not yet borrowed-checked.
High-level picture: The old `Borrows` analysis is now called
`Reservations` (implemented as a newtype wrapper around `Borrows`);
this continues to compute whether a `Rvalue::Ref` can reach a
statement without an intervening `EndRegion`. In addition, we also
track what `Place` each such `Rvalue::Ref` was immediately assigned
to in a given borrow (yay for MIR-structural properties!).
The new `ActiveBorrows` analysis then tracks the initial use of any of
those assigned `Places` for a given borrow. I.e. a borrow becomes
"active" immediately after it starts being "used" in some way. (This
is conservative in the sense that we will treat a copy `x = y;` as a
use of `y`; in principle one might further delay activation in such
cases.)
The new `ActiveBorrows` analysis needs to take the `Reservations`
results as an initial input, because the reservation state influences
the gen/kill sets for `ActiveBorrows`. In particular, a use of `a`
activates a borrow `a = &b` if and only if there exists a path (in the
control flow graph) from the borrow to that use. So we need to know if
the borrow reaches a given use to know if it really gets a gen-bit or
not.
* Incorporating the output from one dataflow analysis into the input
of another required more changes to the infrastructure than I had
expected, and even after those changes, the resulting code is still
a bit subtle.
* In particular, Since we need to know the intrablock reservation
state, we need to dynamically update a bitvector for the
reservations as we are also trying to compute the gen/kills
bitvector for the active borrows.
* The way I ended up deciding to do this (after also toying with at
least two other designs) is to put both the reservation state and
the active borrow state into a single bitvector. That is why we now
have separate (but related) `BorrowIndex` and
`ReserveOrActivateIndex`: each borrow index maps to a pair of
neighboring reservation and activation indexes.
As noted above, these changes are solely adding the active borrows
dataflow analysis (and updating the existing code to cope with the
switch from `Borrows` to `Reservations`). The code to process the
bitvector in the borrow checker currently just skips over all of the
active borrow bits.
But atop this commit, one *can* observe the analysis results by
looking at the graphviz output, e.g. via
```rust
#[rustc_mir(borrowck_graphviz_preflow="pre_two_phase.dot",
borrowck_graphviz_postflow="post_two_phase.dot")]
```
Includes doc for `FindPlaceUses`, as well as `Reservations` and
`ActiveBorrows` structs, which are wrappers are the `Borrows` struct
that dictate which flow analysis should be performed.
2017-12-01 12:32:51 +01:00
|
|
|
fn active(i: BorrowIndex) -> Self { ReserveOrActivateIndex::new((i.index() * 2) + 1) }
|
|
|
|
|
|
|
|
pub(crate) fn is_reservation(self) -> bool { self.index() % 2 == 0 }
|
|
|
|
pub(crate) fn is_activation(self) -> bool { self.index() % 2 == 1}
|
|
|
|
|
|
|
|
pub(crate) fn kind(self) -> &'static str {
|
|
|
|
if self.is_reservation() { "reserved" } else { "active" }
|
|
|
|
}
|
|
|
|
pub(crate) fn borrow_index(self) -> BorrowIndex {
|
|
|
|
BorrowIndex::new(self.index() / 2)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-10-30 05:50:39 -04:00
|
|
|
impl<'a, 'gcx, 'tcx> Borrows<'a, 'gcx, 'tcx> {
|
2017-10-30 08:28:07 -04:00
|
|
|
pub fn new(tcx: TyCtxt<'a, 'gcx, 'tcx>,
|
|
|
|
mir: &'a Mir<'tcx>,
|
2017-12-07 04:30:39 -05:00
|
|
|
nonlexical_regioncx: Option<Rc<RegionInferenceContext<'tcx>>>,
|
2017-12-04 00:56:06 +02:00
|
|
|
def_id: DefId,
|
|
|
|
body_id: Option<hir::BodyId>)
|
2017-10-30 08:28:07 -04:00
|
|
|
-> Self {
|
2017-12-04 00:56:06 +02:00
|
|
|
let scope_tree = tcx.region_scope_tree(def_id);
|
|
|
|
let root_scope = body_id.map(|body_id| {
|
|
|
|
region::Scope::CallSite(tcx.hir.body(body_id).value.hir_id.local_id)
|
|
|
|
});
|
2017-11-16 15:32:13 -08:00
|
|
|
let mut visitor = GatherBorrows {
|
|
|
|
tcx,
|
|
|
|
mir,
|
|
|
|
idx_vec: IndexVec::new(),
|
|
|
|
location_map: FxHashMap(),
|
2018-03-05 02:44:10 -05:00
|
|
|
activation_map: FxHashMap(),
|
2017-11-16 15:32:13 -08:00
|
|
|
region_map: FxHashMap(),
|
2017-12-04 13:21:28 +02:00
|
|
|
local_map: FxHashMap(),
|
2018-03-05 02:44:10 -05:00
|
|
|
region_span_map: FxHashMap(),
|
2018-04-06 11:50:17 -04:00
|
|
|
nonlexical_regioncx: nonlexical_regioncx.clone(),
|
|
|
|
pending_activations: FxHashMap(),
|
2017-11-16 15:32:13 -08:00
|
|
|
};
|
2018-04-06 11:50:17 -04:00
|
|
|
for (block, block_data) in traversal::preorder(mir) {
|
|
|
|
visitor.visit_basic_block_data(block, block_data);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Double check: We should have found an activation for every pending
|
|
|
|
// activation.
|
|
|
|
assert_eq!(
|
|
|
|
visitor
|
|
|
|
.pending_activations
|
|
|
|
.iter()
|
|
|
|
.find(|&(_local, &borrow_index)| {
|
|
|
|
visitor.idx_vec[borrow_index].activation_location.is_none()
|
|
|
|
}),
|
|
|
|
None,
|
|
|
|
"never found an activation for this borrow!",
|
|
|
|
);
|
|
|
|
|
2017-07-03 18:40:20 +02:00
|
|
|
return Borrows { tcx: tcx,
|
|
|
|
mir: mir,
|
|
|
|
borrows: visitor.idx_vec,
|
2017-12-04 00:56:06 +02:00
|
|
|
scope_tree,
|
|
|
|
root_scope,
|
2017-07-03 18:40:20 +02:00
|
|
|
location_map: visitor.location_map,
|
2018-03-05 02:44:10 -05:00
|
|
|
activation_map: visitor.activation_map,
|
2017-09-27 10:01:42 +03:00
|
|
|
region_map: visitor.region_map,
|
2017-12-04 13:21:28 +02:00
|
|
|
local_map: visitor.local_map,
|
2017-10-30 08:28:07 -04:00
|
|
|
region_span_map: visitor.region_span_map,
|
|
|
|
nonlexical_regioncx };
|
2017-07-03 18:40:20 +02:00
|
|
|
|
2017-11-16 15:32:13 -08:00
|
|
|
struct GatherBorrows<'a, 'gcx: 'tcx, 'tcx: 'a> {
|
|
|
|
tcx: TyCtxt<'a, 'gcx, 'tcx>,
|
|
|
|
mir: &'a Mir<'tcx>,
|
2017-07-03 18:40:20 +02:00
|
|
|
idx_vec: IndexVec<BorrowIndex, BorrowData<'tcx>>,
|
|
|
|
location_map: FxHashMap<Location, BorrowIndex>,
|
2018-04-04 23:08:10 -04:00
|
|
|
activation_map: FxHashMap<Location, FxHashSet<BorrowIndex>>,
|
2017-07-03 18:40:20 +02:00
|
|
|
region_map: FxHashMap<Region<'tcx>, FxHashSet<BorrowIndex>>,
|
2017-12-04 13:21:28 +02:00
|
|
|
local_map: FxHashMap<mir::Local, FxHashSet<BorrowIndex>>,
|
2017-09-27 10:01:42 +03:00
|
|
|
region_span_map: FxHashMap<RegionKind, Span>,
|
2018-03-05 02:44:10 -05:00
|
|
|
nonlexical_regioncx: Option<Rc<RegionInferenceContext<'tcx>>>,
|
2018-04-06 11:50:17 -04:00
|
|
|
|
|
|
|
/// When we encounter a 2-phase borrow statement, it will always
|
|
|
|
/// be assigning into a temporary TEMP:
|
|
|
|
///
|
|
|
|
/// TEMP = &foo
|
|
|
|
///
|
|
|
|
/// We add TEMP into this map with `b`, where `b` is the index of
|
|
|
|
/// the borrow. When we find a later use of this activation, we
|
|
|
|
/// remove from the map (and add to the "tombstone" set below).
|
|
|
|
pending_activations: FxHashMap<mir::Local, BorrowIndex>,
|
2017-07-03 18:40:20 +02:00
|
|
|
}
|
2017-11-16 15:32:13 -08:00
|
|
|
|
|
|
|
impl<'a, 'gcx, 'tcx> Visitor<'tcx> for GatherBorrows<'a, 'gcx, 'tcx> {
|
New `ActiveBorrows` dataflow for two-phase `&mut`; not yet borrowed-checked.
High-level picture: The old `Borrows` analysis is now called
`Reservations` (implemented as a newtype wrapper around `Borrows`);
this continues to compute whether a `Rvalue::Ref` can reach a
statement without an intervening `EndRegion`. In addition, we also
track what `Place` each such `Rvalue::Ref` was immediately assigned
to in a given borrow (yay for MIR-structural properties!).
The new `ActiveBorrows` analysis then tracks the initial use of any of
those assigned `Places` for a given borrow. I.e. a borrow becomes
"active" immediately after it starts being "used" in some way. (This
is conservative in the sense that we will treat a copy `x = y;` as a
use of `y`; in principle one might further delay activation in such
cases.)
The new `ActiveBorrows` analysis needs to take the `Reservations`
results as an initial input, because the reservation state influences
the gen/kill sets for `ActiveBorrows`. In particular, a use of `a`
activates a borrow `a = &b` if and only if there exists a path (in the
control flow graph) from the borrow to that use. So we need to know if
the borrow reaches a given use to know if it really gets a gen-bit or
not.
* Incorporating the output from one dataflow analysis into the input
of another required more changes to the infrastructure than I had
expected, and even after those changes, the resulting code is still
a bit subtle.
* In particular, Since we need to know the intrablock reservation
state, we need to dynamically update a bitvector for the
reservations as we are also trying to compute the gen/kills
bitvector for the active borrows.
* The way I ended up deciding to do this (after also toying with at
least two other designs) is to put both the reservation state and
the active borrow state into a single bitvector. That is why we now
have separate (but related) `BorrowIndex` and
`ReserveOrActivateIndex`: each borrow index maps to a pair of
neighboring reservation and activation indexes.
As noted above, these changes are solely adding the active borrows
dataflow analysis (and updating the existing code to cope with the
switch from `Borrows` to `Reservations`). The code to process the
bitvector in the borrow checker currently just skips over all of the
active borrow bits.
But atop this commit, one *can* observe the analysis results by
looking at the graphviz output, e.g. via
```rust
#[rustc_mir(borrowck_graphviz_preflow="pre_two_phase.dot",
borrowck_graphviz_postflow="post_two_phase.dot")]
```
Includes doc for `FindPlaceUses`, as well as `Reservations` and
`ActiveBorrows` structs, which are wrappers are the `Borrows` struct
that dictate which flow analysis should be performed.
2017-12-01 12:32:51 +01:00
|
|
|
fn visit_assign(&mut self,
|
|
|
|
block: mir::BasicBlock,
|
|
|
|
assigned_place: &mir::Place<'tcx>,
|
2017-07-03 18:40:20 +02:00
|
|
|
rvalue: &mir::Rvalue<'tcx>,
|
|
|
|
location: mir::Location) {
|
2017-12-04 13:21:28 +02:00
|
|
|
fn root_local(mut p: &mir::Place<'_>) -> Option<mir::Local> {
|
|
|
|
loop { match p {
|
|
|
|
mir::Place::Projection(pi) => p = &pi.base,
|
|
|
|
mir::Place::Static(_) => return None,
|
|
|
|
mir::Place::Local(l) => return Some(*l)
|
|
|
|
}}
|
|
|
|
}
|
|
|
|
|
New `ActiveBorrows` dataflow for two-phase `&mut`; not yet borrowed-checked.
High-level picture: The old `Borrows` analysis is now called
`Reservations` (implemented as a newtype wrapper around `Borrows`);
this continues to compute whether a `Rvalue::Ref` can reach a
statement without an intervening `EndRegion`. In addition, we also
track what `Place` each such `Rvalue::Ref` was immediately assigned
to in a given borrow (yay for MIR-structural properties!).
The new `ActiveBorrows` analysis then tracks the initial use of any of
those assigned `Places` for a given borrow. I.e. a borrow becomes
"active" immediately after it starts being "used" in some way. (This
is conservative in the sense that we will treat a copy `x = y;` as a
use of `y`; in principle one might further delay activation in such
cases.)
The new `ActiveBorrows` analysis needs to take the `Reservations`
results as an initial input, because the reservation state influences
the gen/kill sets for `ActiveBorrows`. In particular, a use of `a`
activates a borrow `a = &b` if and only if there exists a path (in the
control flow graph) from the borrow to that use. So we need to know if
the borrow reaches a given use to know if it really gets a gen-bit or
not.
* Incorporating the output from one dataflow analysis into the input
of another required more changes to the infrastructure than I had
expected, and even after those changes, the resulting code is still
a bit subtle.
* In particular, Since we need to know the intrablock reservation
state, we need to dynamically update a bitvector for the
reservations as we are also trying to compute the gen/kills
bitvector for the active borrows.
* The way I ended up deciding to do this (after also toying with at
least two other designs) is to put both the reservation state and
the active borrow state into a single bitvector. That is why we now
have separate (but related) `BorrowIndex` and
`ReserveOrActivateIndex`: each borrow index maps to a pair of
neighboring reservation and activation indexes.
As noted above, these changes are solely adding the active borrows
dataflow analysis (and updating the existing code to cope with the
switch from `Borrows` to `Reservations`). The code to process the
bitvector in the borrow checker currently just skips over all of the
active borrow bits.
But atop this commit, one *can* observe the analysis results by
looking at the graphviz output, e.g. via
```rust
#[rustc_mir(borrowck_graphviz_preflow="pre_two_phase.dot",
borrowck_graphviz_postflow="post_two_phase.dot")]
```
Includes doc for `FindPlaceUses`, as well as `Reservations` and
`ActiveBorrows` structs, which are wrappers are the `Borrows` struct
that dictate which flow analysis should be performed.
2017-12-01 12:32:51 +01:00
|
|
|
if let mir::Rvalue::Ref(region, kind, ref borrowed_place) = *rvalue {
|
|
|
|
if is_unsafe_place(self.tcx, self.mir, borrowed_place) { return; }
|
2017-11-16 15:32:13 -08:00
|
|
|
|
2017-07-03 18:40:20 +02:00
|
|
|
let borrow = BorrowData {
|
2018-04-06 11:50:17 -04:00
|
|
|
kind,
|
|
|
|
region,
|
2018-03-04 21:47:39 -05:00
|
|
|
reserve_location: location,
|
2018-04-06 11:50:17 -04:00
|
|
|
activation_location: None,
|
New `ActiveBorrows` dataflow for two-phase `&mut`; not yet borrowed-checked.
High-level picture: The old `Borrows` analysis is now called
`Reservations` (implemented as a newtype wrapper around `Borrows`);
this continues to compute whether a `Rvalue::Ref` can reach a
statement without an intervening `EndRegion`. In addition, we also
track what `Place` each such `Rvalue::Ref` was immediately assigned
to in a given borrow (yay for MIR-structural properties!).
The new `ActiveBorrows` analysis then tracks the initial use of any of
those assigned `Places` for a given borrow. I.e. a borrow becomes
"active" immediately after it starts being "used" in some way. (This
is conservative in the sense that we will treat a copy `x = y;` as a
use of `y`; in principle one might further delay activation in such
cases.)
The new `ActiveBorrows` analysis needs to take the `Reservations`
results as an initial input, because the reservation state influences
the gen/kill sets for `ActiveBorrows`. In particular, a use of `a`
activates a borrow `a = &b` if and only if there exists a path (in the
control flow graph) from the borrow to that use. So we need to know if
the borrow reaches a given use to know if it really gets a gen-bit or
not.
* Incorporating the output from one dataflow analysis into the input
of another required more changes to the infrastructure than I had
expected, and even after those changes, the resulting code is still
a bit subtle.
* In particular, Since we need to know the intrablock reservation
state, we need to dynamically update a bitvector for the
reservations as we are also trying to compute the gen/kills
bitvector for the active borrows.
* The way I ended up deciding to do this (after also toying with at
least two other designs) is to put both the reservation state and
the active borrow state into a single bitvector. That is why we now
have separate (but related) `BorrowIndex` and
`ReserveOrActivateIndex`: each borrow index maps to a pair of
neighboring reservation and activation indexes.
As noted above, these changes are solely adding the active borrows
dataflow analysis (and updating the existing code to cope with the
switch from `Borrows` to `Reservations`). The code to process the
bitvector in the borrow checker currently just skips over all of the
active borrow bits.
But atop this commit, one *can* observe the analysis results by
looking at the graphviz output, e.g. via
```rust
#[rustc_mir(borrowck_graphviz_preflow="pre_two_phase.dot",
borrowck_graphviz_postflow="post_two_phase.dot")]
```
Includes doc for `FindPlaceUses`, as well as `Reservations` and
`ActiveBorrows` structs, which are wrappers are the `Borrows` struct
that dictate which flow analysis should be performed.
2017-12-01 12:32:51 +01:00
|
|
|
borrowed_place: borrowed_place.clone(),
|
|
|
|
assigned_place: assigned_place.clone(),
|
2017-07-03 18:40:20 +02:00
|
|
|
};
|
|
|
|
let idx = self.idx_vec.push(borrow);
|
|
|
|
self.location_map.insert(location, idx);
|
2017-12-04 13:21:28 +02:00
|
|
|
|
2018-04-06 11:50:17 -04:00
|
|
|
self.insert_as_pending_if_two_phase(
|
|
|
|
location,
|
|
|
|
&assigned_place,
|
|
|
|
region,
|
|
|
|
kind,
|
|
|
|
idx,
|
|
|
|
);
|
|
|
|
|
New `ActiveBorrows` dataflow for two-phase `&mut`; not yet borrowed-checked.
High-level picture: The old `Borrows` analysis is now called
`Reservations` (implemented as a newtype wrapper around `Borrows`);
this continues to compute whether a `Rvalue::Ref` can reach a
statement without an intervening `EndRegion`. In addition, we also
track what `Place` each such `Rvalue::Ref` was immediately assigned
to in a given borrow (yay for MIR-structural properties!).
The new `ActiveBorrows` analysis then tracks the initial use of any of
those assigned `Places` for a given borrow. I.e. a borrow becomes
"active" immediately after it starts being "used" in some way. (This
is conservative in the sense that we will treat a copy `x = y;` as a
use of `y`; in principle one might further delay activation in such
cases.)
The new `ActiveBorrows` analysis needs to take the `Reservations`
results as an initial input, because the reservation state influences
the gen/kill sets for `ActiveBorrows`. In particular, a use of `a`
activates a borrow `a = &b` if and only if there exists a path (in the
control flow graph) from the borrow to that use. So we need to know if
the borrow reaches a given use to know if it really gets a gen-bit or
not.
* Incorporating the output from one dataflow analysis into the input
of another required more changes to the infrastructure than I had
expected, and even after those changes, the resulting code is still
a bit subtle.
* In particular, Since we need to know the intrablock reservation
state, we need to dynamically update a bitvector for the
reservations as we are also trying to compute the gen/kills
bitvector for the active borrows.
* The way I ended up deciding to do this (after also toying with at
least two other designs) is to put both the reservation state and
the active borrow state into a single bitvector. That is why we now
have separate (but related) `BorrowIndex` and
`ReserveOrActivateIndex`: each borrow index maps to a pair of
neighboring reservation and activation indexes.
As noted above, these changes are solely adding the active borrows
dataflow analysis (and updating the existing code to cope with the
switch from `Borrows` to `Reservations`). The code to process the
bitvector in the borrow checker currently just skips over all of the
active borrow bits.
But atop this commit, one *can* observe the analysis results by
looking at the graphviz output, e.g. via
```rust
#[rustc_mir(borrowck_graphviz_preflow="pre_two_phase.dot",
borrowck_graphviz_postflow="post_two_phase.dot")]
```
Includes doc for `FindPlaceUses`, as well as `Reservations` and
`ActiveBorrows` structs, which are wrappers are the `Borrows` struct
that dictate which flow analysis should be performed.
2017-12-01 12:32:51 +01:00
|
|
|
insert(&mut self.region_map, ®ion, idx);
|
|
|
|
if let Some(local) = root_local(borrowed_place) {
|
|
|
|
insert(&mut self.local_map, &local, idx);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return self.super_assign(block, assigned_place, rvalue, location);
|
2017-12-04 13:21:28 +02:00
|
|
|
|
New `ActiveBorrows` dataflow for two-phase `&mut`; not yet borrowed-checked.
High-level picture: The old `Borrows` analysis is now called
`Reservations` (implemented as a newtype wrapper around `Borrows`);
this continues to compute whether a `Rvalue::Ref` can reach a
statement without an intervening `EndRegion`. In addition, we also
track what `Place` each such `Rvalue::Ref` was immediately assigned
to in a given borrow (yay for MIR-structural properties!).
The new `ActiveBorrows` analysis then tracks the initial use of any of
those assigned `Places` for a given borrow. I.e. a borrow becomes
"active" immediately after it starts being "used" in some way. (This
is conservative in the sense that we will treat a copy `x = y;` as a
use of `y`; in principle one might further delay activation in such
cases.)
The new `ActiveBorrows` analysis needs to take the `Reservations`
results as an initial input, because the reservation state influences
the gen/kill sets for `ActiveBorrows`. In particular, a use of `a`
activates a borrow `a = &b` if and only if there exists a path (in the
control flow graph) from the borrow to that use. So we need to know if
the borrow reaches a given use to know if it really gets a gen-bit or
not.
* Incorporating the output from one dataflow analysis into the input
of another required more changes to the infrastructure than I had
expected, and even after those changes, the resulting code is still
a bit subtle.
* In particular, Since we need to know the intrablock reservation
state, we need to dynamically update a bitvector for the
reservations as we are also trying to compute the gen/kills
bitvector for the active borrows.
* The way I ended up deciding to do this (after also toying with at
least two other designs) is to put both the reservation state and
the active borrow state into a single bitvector. That is why we now
have separate (but related) `BorrowIndex` and
`ReserveOrActivateIndex`: each borrow index maps to a pair of
neighboring reservation and activation indexes.
As noted above, these changes are solely adding the active borrows
dataflow analysis (and updating the existing code to cope with the
switch from `Borrows` to `Reservations`). The code to process the
bitvector in the borrow checker currently just skips over all of the
active borrow bits.
But atop this commit, one *can* observe the analysis results by
looking at the graphviz output, e.g. via
```rust
#[rustc_mir(borrowck_graphviz_preflow="pre_two_phase.dot",
borrowck_graphviz_postflow="post_two_phase.dot")]
```
Includes doc for `FindPlaceUses`, as well as `Reservations` and
`ActiveBorrows` structs, which are wrappers are the `Borrows` struct
that dictate which flow analysis should be performed.
2017-12-01 12:32:51 +01:00
|
|
|
fn insert<'a, K, V>(map: &'a mut FxHashMap<K, FxHashSet<V>>,
|
|
|
|
k: &K,
|
|
|
|
v: V)
|
|
|
|
where K: Clone+Eq+Hash, V: Eq+Hash
|
|
|
|
{
|
|
|
|
map.entry(k.clone())
|
|
|
|
.or_insert(FxHashSet())
|
|
|
|
.insert(v);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-04-06 11:50:17 -04:00
|
|
|
fn visit_place(
|
|
|
|
&mut self,
|
|
|
|
place: &mir::Place<'tcx>,
|
|
|
|
context: PlaceContext<'tcx>,
|
|
|
|
location: Location,
|
|
|
|
) {
|
|
|
|
self.super_place(place, context, location);
|
|
|
|
|
|
|
|
// We found a use of some temporary TEMP...
|
|
|
|
if let Place::Local(temp) = place {
|
|
|
|
// ... check whether we (earlier) saw a 2-phase borrow like
|
|
|
|
//
|
|
|
|
// TMP = &mut place
|
|
|
|
match self.pending_activations.get(temp) {
|
|
|
|
Some(&borrow_index) => {
|
|
|
|
let borrow_data = &mut self.idx_vec[borrow_index];
|
|
|
|
|
|
|
|
// Watch out: the use of TMP in the borrow
|
|
|
|
// itself doesn't count as an
|
|
|
|
// activation. =)
|
|
|
|
if borrow_data.reserve_location == location
|
|
|
|
&& context == PlaceContext::Store
|
|
|
|
{
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
if let Some(other_activation) = borrow_data.activation_location {
|
|
|
|
span_bug!(
|
|
|
|
self.mir.source_info(location).span,
|
|
|
|
"found two activations for 2-phase borrow temporary {:?}: \
|
|
|
|
{:?} and {:?}",
|
|
|
|
temp,
|
|
|
|
location,
|
|
|
|
other_activation,
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Otherwise, this is the unique later use
|
|
|
|
// that we expect.
|
|
|
|
borrow_data.activation_location = Some(location);
|
|
|
|
self.activation_map
|
|
|
|
.entry(location)
|
|
|
|
.or_insert(FxHashSet())
|
|
|
|
.insert(borrow_index);
|
|
|
|
}
|
|
|
|
|
|
|
|
None => {}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
New `ActiveBorrows` dataflow for two-phase `&mut`; not yet borrowed-checked.
High-level picture: The old `Borrows` analysis is now called
`Reservations` (implemented as a newtype wrapper around `Borrows`);
this continues to compute whether a `Rvalue::Ref` can reach a
statement without an intervening `EndRegion`. In addition, we also
track what `Place` each such `Rvalue::Ref` was immediately assigned
to in a given borrow (yay for MIR-structural properties!).
The new `ActiveBorrows` analysis then tracks the initial use of any of
those assigned `Places` for a given borrow. I.e. a borrow becomes
"active" immediately after it starts being "used" in some way. (This
is conservative in the sense that we will treat a copy `x = y;` as a
use of `y`; in principle one might further delay activation in such
cases.)
The new `ActiveBorrows` analysis needs to take the `Reservations`
results as an initial input, because the reservation state influences
the gen/kill sets for `ActiveBorrows`. In particular, a use of `a`
activates a borrow `a = &b` if and only if there exists a path (in the
control flow graph) from the borrow to that use. So we need to know if
the borrow reaches a given use to know if it really gets a gen-bit or
not.
* Incorporating the output from one dataflow analysis into the input
of another required more changes to the infrastructure than I had
expected, and even after those changes, the resulting code is still
a bit subtle.
* In particular, Since we need to know the intrablock reservation
state, we need to dynamically update a bitvector for the
reservations as we are also trying to compute the gen/kills
bitvector for the active borrows.
* The way I ended up deciding to do this (after also toying with at
least two other designs) is to put both the reservation state and
the active borrow state into a single bitvector. That is why we now
have separate (but related) `BorrowIndex` and
`ReserveOrActivateIndex`: each borrow index maps to a pair of
neighboring reservation and activation indexes.
As noted above, these changes are solely adding the active borrows
dataflow analysis (and updating the existing code to cope with the
switch from `Borrows` to `Reservations`). The code to process the
bitvector in the borrow checker currently just skips over all of the
active borrow bits.
But atop this commit, one *can* observe the analysis results by
looking at the graphviz output, e.g. via
```rust
#[rustc_mir(borrowck_graphviz_preflow="pre_two_phase.dot",
borrowck_graphviz_postflow="post_two_phase.dot")]
```
Includes doc for `FindPlaceUses`, as well as `Reservations` and
`ActiveBorrows` structs, which are wrappers are the `Borrows` struct
that dictate which flow analysis should be performed.
2017-12-01 12:32:51 +01:00
|
|
|
fn visit_rvalue(&mut self,
|
|
|
|
rvalue: &mir::Rvalue<'tcx>,
|
|
|
|
location: mir::Location) {
|
|
|
|
if let mir::Rvalue::Ref(region, kind, ref place) = *rvalue {
|
|
|
|
// double-check that we already registered a BorrowData for this
|
|
|
|
|
2018-04-06 11:50:17 -04:00
|
|
|
let borrow_index = self.location_map[&location];
|
|
|
|
let borrow_data = &self.idx_vec[borrow_index];
|
|
|
|
assert_eq!(borrow_data.reserve_location, location);
|
|
|
|
assert_eq!(borrow_data.kind, kind);
|
|
|
|
assert_eq!(borrow_data.region, region);
|
|
|
|
assert_eq!(borrow_data.borrowed_place, *place);
|
2017-07-03 18:40:20 +02:00
|
|
|
}
|
New `ActiveBorrows` dataflow for two-phase `&mut`; not yet borrowed-checked.
High-level picture: The old `Borrows` analysis is now called
`Reservations` (implemented as a newtype wrapper around `Borrows`);
this continues to compute whether a `Rvalue::Ref` can reach a
statement without an intervening `EndRegion`. In addition, we also
track what `Place` each such `Rvalue::Ref` was immediately assigned
to in a given borrow (yay for MIR-structural properties!).
The new `ActiveBorrows` analysis then tracks the initial use of any of
those assigned `Places` for a given borrow. I.e. a borrow becomes
"active" immediately after it starts being "used" in some way. (This
is conservative in the sense that we will treat a copy `x = y;` as a
use of `y`; in principle one might further delay activation in such
cases.)
The new `ActiveBorrows` analysis needs to take the `Reservations`
results as an initial input, because the reservation state influences
the gen/kill sets for `ActiveBorrows`. In particular, a use of `a`
activates a borrow `a = &b` if and only if there exists a path (in the
control flow graph) from the borrow to that use. So we need to know if
the borrow reaches a given use to know if it really gets a gen-bit or
not.
* Incorporating the output from one dataflow analysis into the input
of another required more changes to the infrastructure than I had
expected, and even after those changes, the resulting code is still
a bit subtle.
* In particular, Since we need to know the intrablock reservation
state, we need to dynamically update a bitvector for the
reservations as we are also trying to compute the gen/kills
bitvector for the active borrows.
* The way I ended up deciding to do this (after also toying with at
least two other designs) is to put both the reservation state and
the active borrow state into a single bitvector. That is why we now
have separate (but related) `BorrowIndex` and
`ReserveOrActivateIndex`: each borrow index maps to a pair of
neighboring reservation and activation indexes.
As noted above, these changes are solely adding the active borrows
dataflow analysis (and updating the existing code to cope with the
switch from `Borrows` to `Reservations`). The code to process the
bitvector in the borrow checker currently just skips over all of the
active borrow bits.
But atop this commit, one *can* observe the analysis results by
looking at the graphviz output, e.g. via
```rust
#[rustc_mir(borrowck_graphviz_preflow="pre_two_phase.dot",
borrowck_graphviz_postflow="post_two_phase.dot")]
```
Includes doc for `FindPlaceUses`, as well as `Reservations` and
`ActiveBorrows` structs, which are wrappers are the `Borrows` struct
that dictate which flow analysis should be performed.
2017-12-01 12:32:51 +01:00
|
|
|
|
|
|
|
return self.super_rvalue(rvalue, location);
|
2017-07-03 18:40:20 +02:00
|
|
|
}
|
2017-09-27 10:01:42 +03:00
|
|
|
|
|
|
|
fn visit_statement(&mut self,
|
|
|
|
block: mir::BasicBlock,
|
|
|
|
statement: &mir::Statement<'tcx>,
|
|
|
|
location: Location) {
|
|
|
|
if let mir::StatementKind::EndRegion(region_scope) = statement.kind {
|
|
|
|
self.region_span_map.insert(ReScope(region_scope), statement.source_info.span);
|
|
|
|
}
|
New `ActiveBorrows` dataflow for two-phase `&mut`; not yet borrowed-checked.
High-level picture: The old `Borrows` analysis is now called
`Reservations` (implemented as a newtype wrapper around `Borrows`);
this continues to compute whether a `Rvalue::Ref` can reach a
statement without an intervening `EndRegion`. In addition, we also
track what `Place` each such `Rvalue::Ref` was immediately assigned
to in a given borrow (yay for MIR-structural properties!).
The new `ActiveBorrows` analysis then tracks the initial use of any of
those assigned `Places` for a given borrow. I.e. a borrow becomes
"active" immediately after it starts being "used" in some way. (This
is conservative in the sense that we will treat a copy `x = y;` as a
use of `y`; in principle one might further delay activation in such
cases.)
The new `ActiveBorrows` analysis needs to take the `Reservations`
results as an initial input, because the reservation state influences
the gen/kill sets for `ActiveBorrows`. In particular, a use of `a`
activates a borrow `a = &b` if and only if there exists a path (in the
control flow graph) from the borrow to that use. So we need to know if
the borrow reaches a given use to know if it really gets a gen-bit or
not.
* Incorporating the output from one dataflow analysis into the input
of another required more changes to the infrastructure than I had
expected, and even after those changes, the resulting code is still
a bit subtle.
* In particular, Since we need to know the intrablock reservation
state, we need to dynamically update a bitvector for the
reservations as we are also trying to compute the gen/kills
bitvector for the active borrows.
* The way I ended up deciding to do this (after also toying with at
least two other designs) is to put both the reservation state and
the active borrow state into a single bitvector. That is why we now
have separate (but related) `BorrowIndex` and
`ReserveOrActivateIndex`: each borrow index maps to a pair of
neighboring reservation and activation indexes.
As noted above, these changes are solely adding the active borrows
dataflow analysis (and updating the existing code to cope with the
switch from `Borrows` to `Reservations`). The code to process the
bitvector in the borrow checker currently just skips over all of the
active borrow bits.
But atop this commit, one *can* observe the analysis results by
looking at the graphviz output, e.g. via
```rust
#[rustc_mir(borrowck_graphviz_preflow="pre_two_phase.dot",
borrowck_graphviz_postflow="post_two_phase.dot")]
```
Includes doc for `FindPlaceUses`, as well as `Reservations` and
`ActiveBorrows` structs, which are wrappers are the `Borrows` struct
that dictate which flow analysis should be performed.
2017-12-01 12:32:51 +01:00
|
|
|
return self.super_statement(block, statement, location);
|
2017-09-27 10:01:42 +03:00
|
|
|
}
|
2017-07-03 18:40:20 +02:00
|
|
|
}
|
2018-03-05 02:44:10 -05:00
|
|
|
|
|
|
|
/// A MIR visitor that determines if a specific place is used in a two-phase activating
|
|
|
|
/// manner in a given chunk of MIR.
|
|
|
|
struct ContainsUseOfPlace<'b, 'tcx: 'b> {
|
|
|
|
target: &'b Place<'tcx>,
|
|
|
|
use_found: bool,
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<'b, 'tcx: 'b> ContainsUseOfPlace<'b, 'tcx> {
|
|
|
|
fn new(place: &'b Place<'tcx>) -> Self {
|
|
|
|
Self { target: place, use_found: false }
|
|
|
|
}
|
|
|
|
|
|
|
|
/// return whether `context` should be considered a "use" of a
|
|
|
|
/// place found in that context. "Uses" activate associated
|
|
|
|
/// borrows (at least when such uses occur while the borrow also
|
|
|
|
/// has a reservation at the time).
|
|
|
|
fn is_potential_use(context: PlaceContext) -> bool {
|
|
|
|
match context {
|
|
|
|
// storage effects on a place do not activate it
|
|
|
|
PlaceContext::StorageLive | PlaceContext::StorageDead => false,
|
|
|
|
|
|
|
|
// validation effects do not activate a place
|
|
|
|
//
|
|
|
|
// FIXME: Should they? Is it just another read? Or can we
|
|
|
|
// guarantee it won't dereference the stored address? How
|
|
|
|
// "deep" does validation go?
|
|
|
|
PlaceContext::Validate => false,
|
|
|
|
|
|
|
|
// FIXME: This is here to not change behaviour from before
|
|
|
|
// AsmOutput existed, but it's not necessarily a pure overwrite.
|
|
|
|
// so it's possible this should activate the place.
|
|
|
|
PlaceContext::AsmOutput |
|
|
|
|
// pure overwrites of a place do not activate it. (note
|
|
|
|
// PlaceContext::Call is solely about dest place)
|
|
|
|
PlaceContext::Store | PlaceContext::Call => false,
|
|
|
|
|
|
|
|
// reads of a place *do* activate it
|
|
|
|
PlaceContext::Move |
|
|
|
|
PlaceContext::Copy |
|
|
|
|
PlaceContext::Drop |
|
|
|
|
PlaceContext::Inspect |
|
|
|
|
PlaceContext::Borrow { .. } |
|
|
|
|
PlaceContext::Projection(..) => true,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<'b, 'tcx: 'b> Visitor<'tcx> for ContainsUseOfPlace<'b, 'tcx> {
|
|
|
|
fn visit_place(&mut self,
|
|
|
|
place: &mir::Place<'tcx>,
|
|
|
|
context: PlaceContext<'tcx>,
|
|
|
|
location: Location) {
|
|
|
|
if Self::is_potential_use(context) && place == self.target {
|
|
|
|
self.use_found = true;
|
|
|
|
return;
|
|
|
|
// There is no need to keep checking the statement, we already found a use
|
|
|
|
}
|
|
|
|
|
|
|
|
self.super_place(place, context, location);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<'a, 'gcx, 'tcx> GatherBorrows<'a, 'gcx, 'tcx> {
|
|
|
|
/// Returns true if the borrow represented by `kind` is
|
|
|
|
/// allowed to be split into separate Reservation and
|
|
|
|
/// Activation phases.
|
|
|
|
fn allow_two_phase_borrow(&self, kind: mir::BorrowKind) -> bool {
|
2018-03-06 04:19:41 -05:00
|
|
|
self.tcx.two_phase_borrows() &&
|
2018-03-05 02:44:10 -05:00
|
|
|
(kind.allows_two_phase_borrow() ||
|
|
|
|
self.tcx.sess.opts.debugging_opts.two_phase_beyond_autoref)
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Returns true if the given location contains an NLL-activating use of the given place
|
|
|
|
fn location_contains_use(&self, location: Location, place: &Place) -> bool {
|
|
|
|
let mut use_checker = ContainsUseOfPlace::new(place);
|
|
|
|
let block = &self.mir.basic_blocks().get(location.block).unwrap_or_else(|| {
|
|
|
|
panic!("could not find block at location {:?}", location);
|
|
|
|
});
|
|
|
|
if location.statement_index != block.statements.len() {
|
|
|
|
// This is a statement
|
|
|
|
let stmt = block.statements.get(location.statement_index).unwrap_or_else(|| {
|
|
|
|
panic!("could not find statement at location {:?}");
|
|
|
|
});
|
|
|
|
use_checker.visit_statement(location.block, stmt, location);
|
|
|
|
} else {
|
|
|
|
// This is a terminator
|
|
|
|
match block.terminator {
|
|
|
|
Some(ref term) => {
|
|
|
|
use_checker.visit_terminator(location.block, term, location);
|
|
|
|
}
|
|
|
|
None => {
|
|
|
|
// There is no way for Place to be used by the terminator if there is no
|
|
|
|
// terminator
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
use_checker.use_found
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Determines if the provided region is terminated after the provided location.
|
|
|
|
/// EndRegion statements terminate their enclosed region::Scope.
|
|
|
|
/// We also consult with the NLL region inference engine, should one be available
|
|
|
|
fn region_terminated_after(&self, region: Region<'tcx>, location: Location) -> bool {
|
|
|
|
let block_data = &self.mir[location.block];
|
|
|
|
if location.statement_index != block_data.statements.len() {
|
|
|
|
let stmt = &block_data.statements[location.statement_index];
|
|
|
|
if let mir::StatementKind::EndRegion(region_scope) = stmt.kind {
|
|
|
|
if &ReScope(region_scope) == region {
|
2018-03-06 03:37:21 -05:00
|
|
|
// We encountered an EndRegion statement that terminates the provided
|
|
|
|
// region
|
2018-03-05 02:44:10 -05:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if let Some(ref regioncx) = self.nonlexical_regioncx {
|
|
|
|
if !regioncx.region_contains_point(region, location) {
|
|
|
|
// NLL says the region has ended already
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
false
|
|
|
|
}
|
|
|
|
|
2018-04-06 11:50:17 -04:00
|
|
|
/// If this is a two-phase borrow, then we will record it
|
|
|
|
/// as "pending" until we find the activating use.
|
|
|
|
fn insert_as_pending_if_two_phase(
|
|
|
|
&mut self,
|
|
|
|
start_location: Location,
|
|
|
|
assigned_place: &mir::Place<'tcx>,
|
|
|
|
region: Region<'tcx>,
|
|
|
|
kind: mir::BorrowKind,
|
|
|
|
borrow_index: BorrowIndex,
|
|
|
|
) {
|
|
|
|
debug!(
|
|
|
|
"Borrows::insert_as_pending_if_two_phase({:?}, {:?}, {:?}, {:?})",
|
|
|
|
start_location, assigned_place, region, borrow_index,
|
|
|
|
);
|
|
|
|
|
2018-03-05 02:44:10 -05:00
|
|
|
if !self.allow_two_phase_borrow(kind) {
|
|
|
|
debug!(" -> {:?}", start_location);
|
2018-04-06 11:50:17 -04:00
|
|
|
return;
|
2018-03-05 02:44:10 -05:00
|
|
|
}
|
|
|
|
|
2018-04-06 11:50:17 -04:00
|
|
|
// When we encounter a 2-phase borrow statement, it will always
|
|
|
|
// be assigning into a temporary TEMP:
|
|
|
|
//
|
|
|
|
// TEMP = &foo
|
|
|
|
//
|
|
|
|
// so extract `temp`.
|
|
|
|
let temp = if let &mir::Place::Local(temp) = assigned_place {
|
|
|
|
temp
|
|
|
|
} else {
|
|
|
|
span_bug!(
|
|
|
|
self.mir.source_info(start_location).span,
|
|
|
|
"expected 2-phase borrow to assign to a local, not `{:?}`",
|
|
|
|
assigned_place,
|
|
|
|
);
|
|
|
|
};
|
|
|
|
|
|
|
|
// Insert `temp` into the list of pending activations. From
|
|
|
|
// now on, we'll be on the lookout for a use of it. Note that
|
|
|
|
// we are guaranteed that this use will come after the
|
|
|
|
// assignment.
|
|
|
|
let old_value = self.pending_activations.insert(temp, borrow_index);
|
|
|
|
assert!(old_value.is_none());
|
2018-03-05 02:44:10 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Returns the span for the "end point" given region. This will
|
|
|
|
/// return `None` if NLL is enabled, since that concept has no
|
|
|
|
/// meaning there. Otherwise, return region span if it exists and
|
|
|
|
/// span for end of the function if it doesn't exist.
|
|
|
|
pub(crate) fn opt_region_end_span(&self, region: &Region) -> Option<Span> {
|
|
|
|
match self.nonlexical_regioncx {
|
|
|
|
Some(_) => None,
|
|
|
|
None => {
|
|
|
|
match self.region_span_map.get(region) {
|
|
|
|
Some(span) => Some(self.tcx.sess.codemap().end_point(*span)),
|
|
|
|
None => Some(self.tcx.sess.codemap().end_point(self.mir.span))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2017-07-03 18:40:20 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
pub fn borrows(&self) -> &IndexVec<BorrowIndex, BorrowData<'tcx>> { &self.borrows }
|
|
|
|
|
2018-02-27 17:11:14 +01:00
|
|
|
pub fn scope_tree(&self) -> &Lrc<region::ScopeTree> { &self.scope_tree }
|
2017-12-10 17:00:20 +00:00
|
|
|
|
2017-07-03 18:40:20 +02:00
|
|
|
pub fn location(&self, idx: BorrowIndex) -> &Location {
|
2018-03-04 21:47:39 -05:00
|
|
|
&self.borrows[idx].reserve_location
|
2017-07-03 18:40:20 +02:00
|
|
|
}
|
2017-09-27 10:01:42 +03:00
|
|
|
|
2017-10-30 08:28:07 -04:00
|
|
|
/// Add all borrows to the kill set, if those borrows are out of scope at `location`.
|
2018-03-05 02:44:10 -05:00
|
|
|
/// That means either they went out of either a nonlexical scope, if we care about those
|
|
|
|
/// at the moment, or the location represents a lexical EndRegion
|
2017-10-30 08:28:07 -04:00
|
|
|
fn kill_loans_out_of_scope_at_location(&self,
|
New `ActiveBorrows` dataflow for two-phase `&mut`; not yet borrowed-checked.
High-level picture: The old `Borrows` analysis is now called
`Reservations` (implemented as a newtype wrapper around `Borrows`);
this continues to compute whether a `Rvalue::Ref` can reach a
statement without an intervening `EndRegion`. In addition, we also
track what `Place` each such `Rvalue::Ref` was immediately assigned
to in a given borrow (yay for MIR-structural properties!).
The new `ActiveBorrows` analysis then tracks the initial use of any of
those assigned `Places` for a given borrow. I.e. a borrow becomes
"active" immediately after it starts being "used" in some way. (This
is conservative in the sense that we will treat a copy `x = y;` as a
use of `y`; in principle one might further delay activation in such
cases.)
The new `ActiveBorrows` analysis needs to take the `Reservations`
results as an initial input, because the reservation state influences
the gen/kill sets for `ActiveBorrows`. In particular, a use of `a`
activates a borrow `a = &b` if and only if there exists a path (in the
control flow graph) from the borrow to that use. So we need to know if
the borrow reaches a given use to know if it really gets a gen-bit or
not.
* Incorporating the output from one dataflow analysis into the input
of another required more changes to the infrastructure than I had
expected, and even after those changes, the resulting code is still
a bit subtle.
* In particular, Since we need to know the intrablock reservation
state, we need to dynamically update a bitvector for the
reservations as we are also trying to compute the gen/kills
bitvector for the active borrows.
* The way I ended up deciding to do this (after also toying with at
least two other designs) is to put both the reservation state and
the active borrow state into a single bitvector. That is why we now
have separate (but related) `BorrowIndex` and
`ReserveOrActivateIndex`: each borrow index maps to a pair of
neighboring reservation and activation indexes.
As noted above, these changes are solely adding the active borrows
dataflow analysis (and updating the existing code to cope with the
switch from `Borrows` to `Reservations`). The code to process the
bitvector in the borrow checker currently just skips over all of the
active borrow bits.
But atop this commit, one *can* observe the analysis results by
looking at the graphviz output, e.g. via
```rust
#[rustc_mir(borrowck_graphviz_preflow="pre_two_phase.dot",
borrowck_graphviz_postflow="post_two_phase.dot")]
```
Includes doc for `FindPlaceUses`, as well as `Reservations` and
`ActiveBorrows` structs, which are wrappers are the `Borrows` struct
that dictate which flow analysis should be performed.
2017-12-01 12:32:51 +01:00
|
|
|
sets: &mut BlockSets<ReserveOrActivateIndex>,
|
2018-03-05 02:44:10 -05:00
|
|
|
location: Location) {
|
2017-11-17 04:34:02 -05:00
|
|
|
if let Some(ref regioncx) = self.nonlexical_regioncx {
|
2017-12-13 18:10:37 -06:00
|
|
|
// NOTE: The state associated with a given `location`
|
|
|
|
// reflects the dataflow on entry to the statement. If it
|
|
|
|
// does not contain `borrow_region`, then then that means
|
|
|
|
// that the statement at `location` kills the borrow.
|
|
|
|
//
|
|
|
|
// We are careful always to call this function *before* we
|
|
|
|
// set up the gen-bits for the statement or
|
|
|
|
// termanator. That way, if the effect of the statement or
|
|
|
|
// terminator *does* introduce a new loan of the same
|
|
|
|
// region, then setting that gen-bit will override any
|
|
|
|
// potential kill introduced here.
|
2017-10-30 08:28:07 -04:00
|
|
|
for (borrow_index, borrow_data) in self.borrows.iter_enumerated() {
|
2017-11-06 04:15:38 -05:00
|
|
|
let borrow_region = borrow_data.region.to_region_vid();
|
2017-10-30 05:14:40 -04:00
|
|
|
if !regioncx.region_contains_point(borrow_region, location) {
|
2017-12-13 18:10:37 -06:00
|
|
|
sets.kill(&ReserveOrActivateIndex::reserved(borrow_index));
|
2018-03-05 02:44:10 -05:00
|
|
|
sets.kill(&ReserveOrActivateIndex::active(borrow_index));
|
2017-10-30 08:28:07 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2017-07-03 18:40:20 +02:00
|
|
|
|
2018-03-05 02:44:10 -05:00
|
|
|
fn kill_borrows_on_local(&self,
|
|
|
|
sets: &mut BlockSets<ReserveOrActivateIndex>,
|
|
|
|
local: &rustc::mir::Local)
|
|
|
|
{
|
|
|
|
if let Some(borrow_indexes) = self.local_map.get(local) {
|
|
|
|
sets.kill_all(borrow_indexes.iter()
|
|
|
|
.map(|b| ReserveOrActivateIndex::reserved(*b)));
|
|
|
|
sets.kill_all(borrow_indexes.iter()
|
|
|
|
.map(|b| ReserveOrActivateIndex::active(*b)));
|
|
|
|
}
|
|
|
|
}
|
2018-03-05 22:43:43 -05:00
|
|
|
|
|
|
|
/// Performs the activations for a given location
|
|
|
|
fn perform_activations_at_location(&self,
|
|
|
|
sets: &mut BlockSets<ReserveOrActivateIndex>,
|
|
|
|
location: Location) {
|
|
|
|
// Handle activations
|
|
|
|
match self.activation_map.get(&location) {
|
2018-04-04 23:08:10 -04:00
|
|
|
Some(activations) => {
|
|
|
|
for activated in activations {
|
|
|
|
debug!("activating borrow {:?}", activated);
|
|
|
|
sets.gen(&ReserveOrActivateIndex::active(*activated))
|
|
|
|
}
|
2018-03-05 22:43:43 -05:00
|
|
|
}
|
|
|
|
None => {}
|
|
|
|
}
|
|
|
|
}
|
2018-03-05 02:44:10 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
impl<'a, 'gcx, 'tcx> BitDenotation for Borrows<'a, 'gcx, 'tcx> {
|
|
|
|
type Idx = ReserveOrActivateIndex;
|
|
|
|
fn name() -> &'static str { "borrows" }
|
|
|
|
fn bits_per_block(&self) -> usize {
|
|
|
|
self.borrows.len() * 2
|
|
|
|
}
|
|
|
|
|
|
|
|
fn start_block_effect(&self, _entry_set: &mut IdxSet<ReserveOrActivateIndex>) {
|
|
|
|
// no borrows of code region_scopes have been taken prior to
|
|
|
|
// function execution, so this method has no effect on
|
|
|
|
// `_sets`.
|
|
|
|
}
|
|
|
|
|
2018-03-06 03:37:21 -05:00
|
|
|
fn before_statement_effect(&self,
|
|
|
|
sets: &mut BlockSets<ReserveOrActivateIndex>,
|
|
|
|
location: Location) {
|
2018-03-05 02:44:10 -05:00
|
|
|
debug!("Borrows::before_statement_effect sets: {:?} location: {:?}", sets, location);
|
|
|
|
self.kill_loans_out_of_scope_at_location(sets, location);
|
|
|
|
}
|
|
|
|
|
|
|
|
fn statement_effect(&self, sets: &mut BlockSets<ReserveOrActivateIndex>, location: Location) {
|
|
|
|
debug!("Borrows::statement_effect sets: {:?} location: {:?}", sets, location);
|
|
|
|
|
2017-07-03 18:40:20 +02:00
|
|
|
let block = &self.mir.basic_blocks().get(location.block).unwrap_or_else(|| {
|
|
|
|
panic!("could not find block at location {:?}", location);
|
|
|
|
});
|
|
|
|
let stmt = block.statements.get(location.statement_index).unwrap_or_else(|| {
|
|
|
|
panic!("could not find statement at location {:?}");
|
|
|
|
});
|
New `ActiveBorrows` dataflow for two-phase `&mut`; not yet borrowed-checked.
High-level picture: The old `Borrows` analysis is now called
`Reservations` (implemented as a newtype wrapper around `Borrows`);
this continues to compute whether a `Rvalue::Ref` can reach a
statement without an intervening `EndRegion`. In addition, we also
track what `Place` each such `Rvalue::Ref` was immediately assigned
to in a given borrow (yay for MIR-structural properties!).
The new `ActiveBorrows` analysis then tracks the initial use of any of
those assigned `Places` for a given borrow. I.e. a borrow becomes
"active" immediately after it starts being "used" in some way. (This
is conservative in the sense that we will treat a copy `x = y;` as a
use of `y`; in principle one might further delay activation in such
cases.)
The new `ActiveBorrows` analysis needs to take the `Reservations`
results as an initial input, because the reservation state influences
the gen/kill sets for `ActiveBorrows`. In particular, a use of `a`
activates a borrow `a = &b` if and only if there exists a path (in the
control flow graph) from the borrow to that use. So we need to know if
the borrow reaches a given use to know if it really gets a gen-bit or
not.
* Incorporating the output from one dataflow analysis into the input
of another required more changes to the infrastructure than I had
expected, and even after those changes, the resulting code is still
a bit subtle.
* In particular, Since we need to know the intrablock reservation
state, we need to dynamically update a bitvector for the
reservations as we are also trying to compute the gen/kills
bitvector for the active borrows.
* The way I ended up deciding to do this (after also toying with at
least two other designs) is to put both the reservation state and
the active borrow state into a single bitvector. That is why we now
have separate (but related) `BorrowIndex` and
`ReserveOrActivateIndex`: each borrow index maps to a pair of
neighboring reservation and activation indexes.
As noted above, these changes are solely adding the active borrows
dataflow analysis (and updating the existing code to cope with the
switch from `Borrows` to `Reservations`). The code to process the
bitvector in the borrow checker currently just skips over all of the
active borrow bits.
But atop this commit, one *can* observe the analysis results by
looking at the graphviz output, e.g. via
```rust
#[rustc_mir(borrowck_graphviz_preflow="pre_two_phase.dot",
borrowck_graphviz_postflow="post_two_phase.dot")]
```
Includes doc for `FindPlaceUses`, as well as `Reservations` and
`ActiveBorrows` structs, which are wrappers are the `Borrows` struct
that dictate which flow analysis should be performed.
2017-12-01 12:32:51 +01:00
|
|
|
|
2018-03-05 22:43:43 -05:00
|
|
|
self.perform_activations_at_location(sets, location);
|
|
|
|
self.kill_loans_out_of_scope_at_location(sets, location);
|
New `ActiveBorrows` dataflow for two-phase `&mut`; not yet borrowed-checked.
High-level picture: The old `Borrows` analysis is now called
`Reservations` (implemented as a newtype wrapper around `Borrows`);
this continues to compute whether a `Rvalue::Ref` can reach a
statement without an intervening `EndRegion`. In addition, we also
track what `Place` each such `Rvalue::Ref` was immediately assigned
to in a given borrow (yay for MIR-structural properties!).
The new `ActiveBorrows` analysis then tracks the initial use of any of
those assigned `Places` for a given borrow. I.e. a borrow becomes
"active" immediately after it starts being "used" in some way. (This
is conservative in the sense that we will treat a copy `x = y;` as a
use of `y`; in principle one might further delay activation in such
cases.)
The new `ActiveBorrows` analysis needs to take the `Reservations`
results as an initial input, because the reservation state influences
the gen/kill sets for `ActiveBorrows`. In particular, a use of `a`
activates a borrow `a = &b` if and only if there exists a path (in the
control flow graph) from the borrow to that use. So we need to know if
the borrow reaches a given use to know if it really gets a gen-bit or
not.
* Incorporating the output from one dataflow analysis into the input
of another required more changes to the infrastructure than I had
expected, and even after those changes, the resulting code is still
a bit subtle.
* In particular, Since we need to know the intrablock reservation
state, we need to dynamically update a bitvector for the
reservations as we are also trying to compute the gen/kills
bitvector for the active borrows.
* The way I ended up deciding to do this (after also toying with at
least two other designs) is to put both the reservation state and
the active borrow state into a single bitvector. That is why we now
have separate (but related) `BorrowIndex` and
`ReserveOrActivateIndex`: each borrow index maps to a pair of
neighboring reservation and activation indexes.
As noted above, these changes are solely adding the active borrows
dataflow analysis (and updating the existing code to cope with the
switch from `Borrows` to `Reservations`). The code to process the
bitvector in the borrow checker currently just skips over all of the
active borrow bits.
But atop this commit, one *can* observe the analysis results by
looking at the graphviz output, e.g. via
```rust
#[rustc_mir(borrowck_graphviz_preflow="pre_two_phase.dot",
borrowck_graphviz_postflow="post_two_phase.dot")]
```
Includes doc for `FindPlaceUses`, as well as `Reservations` and
`ActiveBorrows` structs, which are wrappers are the `Borrows` struct
that dictate which flow analysis should be performed.
2017-12-01 12:32:51 +01:00
|
|
|
|
2017-07-03 18:40:20 +02:00
|
|
|
match stmt.kind {
|
New `ActiveBorrows` dataflow for two-phase `&mut`; not yet borrowed-checked.
High-level picture: The old `Borrows` analysis is now called
`Reservations` (implemented as a newtype wrapper around `Borrows`);
this continues to compute whether a `Rvalue::Ref` can reach a
statement without an intervening `EndRegion`. In addition, we also
track what `Place` each such `Rvalue::Ref` was immediately assigned
to in a given borrow (yay for MIR-structural properties!).
The new `ActiveBorrows` analysis then tracks the initial use of any of
those assigned `Places` for a given borrow. I.e. a borrow becomes
"active" immediately after it starts being "used" in some way. (This
is conservative in the sense that we will treat a copy `x = y;` as a
use of `y`; in principle one might further delay activation in such
cases.)
The new `ActiveBorrows` analysis needs to take the `Reservations`
results as an initial input, because the reservation state influences
the gen/kill sets for `ActiveBorrows`. In particular, a use of `a`
activates a borrow `a = &b` if and only if there exists a path (in the
control flow graph) from the borrow to that use. So we need to know if
the borrow reaches a given use to know if it really gets a gen-bit or
not.
* Incorporating the output from one dataflow analysis into the input
of another required more changes to the infrastructure than I had
expected, and even after those changes, the resulting code is still
a bit subtle.
* In particular, Since we need to know the intrablock reservation
state, we need to dynamically update a bitvector for the
reservations as we are also trying to compute the gen/kills
bitvector for the active borrows.
* The way I ended up deciding to do this (after also toying with at
least two other designs) is to put both the reservation state and
the active borrow state into a single bitvector. That is why we now
have separate (but related) `BorrowIndex` and
`ReserveOrActivateIndex`: each borrow index maps to a pair of
neighboring reservation and activation indexes.
As noted above, these changes are solely adding the active borrows
dataflow analysis (and updating the existing code to cope with the
switch from `Borrows` to `Reservations`). The code to process the
bitvector in the borrow checker currently just skips over all of the
active borrow bits.
But atop this commit, one *can* observe the analysis results by
looking at the graphviz output, e.g. via
```rust
#[rustc_mir(borrowck_graphviz_preflow="pre_two_phase.dot",
borrowck_graphviz_postflow="post_two_phase.dot")]
```
Includes doc for `FindPlaceUses`, as well as `Reservations` and
`ActiveBorrows` structs, which are wrappers are the `Borrows` struct
that dictate which flow analysis should be performed.
2017-12-01 12:32:51 +01:00
|
|
|
// EndRegion kills any borrows (reservations and active borrows both)
|
2017-08-31 21:37:38 +03:00
|
|
|
mir::StatementKind::EndRegion(region_scope) => {
|
2017-10-02 22:40:51 +02:00
|
|
|
if let Some(borrow_indexes) = self.region_map.get(&ReScope(region_scope)) {
|
2017-10-30 08:28:07 -04:00
|
|
|
assert!(self.nonlexical_regioncx.is_none());
|
New `ActiveBorrows` dataflow for two-phase `&mut`; not yet borrowed-checked.
High-level picture: The old `Borrows` analysis is now called
`Reservations` (implemented as a newtype wrapper around `Borrows`);
this continues to compute whether a `Rvalue::Ref` can reach a
statement without an intervening `EndRegion`. In addition, we also
track what `Place` each such `Rvalue::Ref` was immediately assigned
to in a given borrow (yay for MIR-structural properties!).
The new `ActiveBorrows` analysis then tracks the initial use of any of
those assigned `Places` for a given borrow. I.e. a borrow becomes
"active" immediately after it starts being "used" in some way. (This
is conservative in the sense that we will treat a copy `x = y;` as a
use of `y`; in principle one might further delay activation in such
cases.)
The new `ActiveBorrows` analysis needs to take the `Reservations`
results as an initial input, because the reservation state influences
the gen/kill sets for `ActiveBorrows`. In particular, a use of `a`
activates a borrow `a = &b` if and only if there exists a path (in the
control flow graph) from the borrow to that use. So we need to know if
the borrow reaches a given use to know if it really gets a gen-bit or
not.
* Incorporating the output from one dataflow analysis into the input
of another required more changes to the infrastructure than I had
expected, and even after those changes, the resulting code is still
a bit subtle.
* In particular, Since we need to know the intrablock reservation
state, we need to dynamically update a bitvector for the
reservations as we are also trying to compute the gen/kills
bitvector for the active borrows.
* The way I ended up deciding to do this (after also toying with at
least two other designs) is to put both the reservation state and
the active borrow state into a single bitvector. That is why we now
have separate (but related) `BorrowIndex` and
`ReserveOrActivateIndex`: each borrow index maps to a pair of
neighboring reservation and activation indexes.
As noted above, these changes are solely adding the active borrows
dataflow analysis (and updating the existing code to cope with the
switch from `Borrows` to `Reservations`). The code to process the
bitvector in the borrow checker currently just skips over all of the
active borrow bits.
But atop this commit, one *can* observe the analysis results by
looking at the graphviz output, e.g. via
```rust
#[rustc_mir(borrowck_graphviz_preflow="pre_two_phase.dot",
borrowck_graphviz_postflow="post_two_phase.dot")]
```
Includes doc for `FindPlaceUses`, as well as `Reservations` and
`ActiveBorrows` structs, which are wrappers are the `Borrows` struct
that dictate which flow analysis should be performed.
2017-12-01 12:32:51 +01:00
|
|
|
for idx in borrow_indexes {
|
|
|
|
sets.kill(&ReserveOrActivateIndex::reserved(*idx));
|
2018-03-05 02:44:10 -05:00
|
|
|
sets.kill(&ReserveOrActivateIndex::active(*idx));
|
New `ActiveBorrows` dataflow for two-phase `&mut`; not yet borrowed-checked.
High-level picture: The old `Borrows` analysis is now called
`Reservations` (implemented as a newtype wrapper around `Borrows`);
this continues to compute whether a `Rvalue::Ref` can reach a
statement without an intervening `EndRegion`. In addition, we also
track what `Place` each such `Rvalue::Ref` was immediately assigned
to in a given borrow (yay for MIR-structural properties!).
The new `ActiveBorrows` analysis then tracks the initial use of any of
those assigned `Places` for a given borrow. I.e. a borrow becomes
"active" immediately after it starts being "used" in some way. (This
is conservative in the sense that we will treat a copy `x = y;` as a
use of `y`; in principle one might further delay activation in such
cases.)
The new `ActiveBorrows` analysis needs to take the `Reservations`
results as an initial input, because the reservation state influences
the gen/kill sets for `ActiveBorrows`. In particular, a use of `a`
activates a borrow `a = &b` if and only if there exists a path (in the
control flow graph) from the borrow to that use. So we need to know if
the borrow reaches a given use to know if it really gets a gen-bit or
not.
* Incorporating the output from one dataflow analysis into the input
of another required more changes to the infrastructure than I had
expected, and even after those changes, the resulting code is still
a bit subtle.
* In particular, Since we need to know the intrablock reservation
state, we need to dynamically update a bitvector for the
reservations as we are also trying to compute the gen/kills
bitvector for the active borrows.
* The way I ended up deciding to do this (after also toying with at
least two other designs) is to put both the reservation state and
the active borrow state into a single bitvector. That is why we now
have separate (but related) `BorrowIndex` and
`ReserveOrActivateIndex`: each borrow index maps to a pair of
neighboring reservation and activation indexes.
As noted above, these changes are solely adding the active borrows
dataflow analysis (and updating the existing code to cope with the
switch from `Borrows` to `Reservations`). The code to process the
bitvector in the borrow checker currently just skips over all of the
active borrow bits.
But atop this commit, one *can* observe the analysis results by
looking at the graphviz output, e.g. via
```rust
#[rustc_mir(borrowck_graphviz_preflow="pre_two_phase.dot",
borrowck_graphviz_postflow="post_two_phase.dot")]
```
Includes doc for `FindPlaceUses`, as well as `Reservations` and
`ActiveBorrows` structs, which are wrappers are the `Borrows` struct
that dictate which flow analysis should be performed.
2017-12-01 12:32:51 +01:00
|
|
|
}
|
2017-10-02 22:40:51 +02:00
|
|
|
} else {
|
|
|
|
// (if there is no entry, then there are no borrows to be tracked)
|
|
|
|
}
|
2017-07-03 18:40:20 +02:00
|
|
|
}
|
|
|
|
|
2017-12-20 18:15:33 +01:00
|
|
|
mir::StatementKind::Assign(ref lhs, ref rhs) => {
|
2017-12-15 14:27:06 -06:00
|
|
|
// Make sure there are no remaining borrows for variables
|
|
|
|
// that are assigned over.
|
|
|
|
if let Place::Local(ref local) = *lhs {
|
|
|
|
// FIXME: Handle the case in which we're assigning over
|
|
|
|
// a projection (`foo.bar`).
|
2018-03-05 02:44:10 -05:00
|
|
|
self.kill_borrows_on_local(sets, local);
|
2017-12-15 14:27:06 -06:00
|
|
|
}
|
|
|
|
|
New `ActiveBorrows` dataflow for two-phase `&mut`; not yet borrowed-checked.
High-level picture: The old `Borrows` analysis is now called
`Reservations` (implemented as a newtype wrapper around `Borrows`);
this continues to compute whether a `Rvalue::Ref` can reach a
statement without an intervening `EndRegion`. In addition, we also
track what `Place` each such `Rvalue::Ref` was immediately assigned
to in a given borrow (yay for MIR-structural properties!).
The new `ActiveBorrows` analysis then tracks the initial use of any of
those assigned `Places` for a given borrow. I.e. a borrow becomes
"active" immediately after it starts being "used" in some way. (This
is conservative in the sense that we will treat a copy `x = y;` as a
use of `y`; in principle one might further delay activation in such
cases.)
The new `ActiveBorrows` analysis needs to take the `Reservations`
results as an initial input, because the reservation state influences
the gen/kill sets for `ActiveBorrows`. In particular, a use of `a`
activates a borrow `a = &b` if and only if there exists a path (in the
control flow graph) from the borrow to that use. So we need to know if
the borrow reaches a given use to know if it really gets a gen-bit or
not.
* Incorporating the output from one dataflow analysis into the input
of another required more changes to the infrastructure than I had
expected, and even after those changes, the resulting code is still
a bit subtle.
* In particular, Since we need to know the intrablock reservation
state, we need to dynamically update a bitvector for the
reservations as we are also trying to compute the gen/kills
bitvector for the active borrows.
* The way I ended up deciding to do this (after also toying with at
least two other designs) is to put both the reservation state and
the active borrow state into a single bitvector. That is why we now
have separate (but related) `BorrowIndex` and
`ReserveOrActivateIndex`: each borrow index maps to a pair of
neighboring reservation and activation indexes.
As noted above, these changes are solely adding the active borrows
dataflow analysis (and updating the existing code to cope with the
switch from `Borrows` to `Reservations`). The code to process the
bitvector in the borrow checker currently just skips over all of the
active borrow bits.
But atop this commit, one *can* observe the analysis results by
looking at the graphviz output, e.g. via
```rust
#[rustc_mir(borrowck_graphviz_preflow="pre_two_phase.dot",
borrowck_graphviz_postflow="post_two_phase.dot")]
```
Includes doc for `FindPlaceUses`, as well as `Reservations` and
`ActiveBorrows` structs, which are wrappers are the `Borrows` struct
that dictate which flow analysis should be performed.
2017-12-01 12:32:51 +01:00
|
|
|
// NOTE: if/when the Assign case is revised to inspect
|
|
|
|
// the assigned_place here, make sure to also
|
|
|
|
// re-consider the current implementations of the
|
|
|
|
// propagate_call_return method.
|
|
|
|
|
2017-12-01 14:39:51 +02:00
|
|
|
if let mir::Rvalue::Ref(region, _, ref place) = *rhs {
|
|
|
|
if is_unsafe_place(self.tcx, self.mir, place) { return; }
|
2018-03-05 22:43:43 -05:00
|
|
|
let index = self.location_map.get(&location).unwrap_or_else(|| {
|
|
|
|
panic!("could not find BorrowIndex for location {:?}", location);
|
|
|
|
});
|
|
|
|
|
2017-11-27 18:13:40 +02:00
|
|
|
if let RegionKind::ReEmpty = region {
|
2018-03-05 22:43:43 -05:00
|
|
|
// If the borrowed value dies before the borrow is used, the region for
|
|
|
|
// the borrow can be empty. Don't track the borrow in that case.
|
|
|
|
sets.kill(&ReserveOrActivateIndex::active(*index));
|
2017-11-27 18:13:40 +02:00
|
|
|
return
|
|
|
|
}
|
|
|
|
|
2017-07-03 18:40:20 +02:00
|
|
|
assert!(self.region_map.get(region).unwrap_or_else(|| {
|
|
|
|
panic!("could not find BorrowIndexs for region {:?}", region);
|
|
|
|
}).contains(&index));
|
New `ActiveBorrows` dataflow for two-phase `&mut`; not yet borrowed-checked.
High-level picture: The old `Borrows` analysis is now called
`Reservations` (implemented as a newtype wrapper around `Borrows`);
this continues to compute whether a `Rvalue::Ref` can reach a
statement without an intervening `EndRegion`. In addition, we also
track what `Place` each such `Rvalue::Ref` was immediately assigned
to in a given borrow (yay for MIR-structural properties!).
The new `ActiveBorrows` analysis then tracks the initial use of any of
those assigned `Places` for a given borrow. I.e. a borrow becomes
"active" immediately after it starts being "used" in some way. (This
is conservative in the sense that we will treat a copy `x = y;` as a
use of `y`; in principle one might further delay activation in such
cases.)
The new `ActiveBorrows` analysis needs to take the `Reservations`
results as an initial input, because the reservation state influences
the gen/kill sets for `ActiveBorrows`. In particular, a use of `a`
activates a borrow `a = &b` if and only if there exists a path (in the
control flow graph) from the borrow to that use. So we need to know if
the borrow reaches a given use to know if it really gets a gen-bit or
not.
* Incorporating the output from one dataflow analysis into the input
of another required more changes to the infrastructure than I had
expected, and even after those changes, the resulting code is still
a bit subtle.
* In particular, Since we need to know the intrablock reservation
state, we need to dynamically update a bitvector for the
reservations as we are also trying to compute the gen/kills
bitvector for the active borrows.
* The way I ended up deciding to do this (after also toying with at
least two other designs) is to put both the reservation state and
the active borrow state into a single bitvector. That is why we now
have separate (but related) `BorrowIndex` and
`ReserveOrActivateIndex`: each borrow index maps to a pair of
neighboring reservation and activation indexes.
As noted above, these changes are solely adding the active borrows
dataflow analysis (and updating the existing code to cope with the
switch from `Borrows` to `Reservations`). The code to process the
bitvector in the borrow checker currently just skips over all of the
active borrow bits.
But atop this commit, one *can* observe the analysis results by
looking at the graphviz output, e.g. via
```rust
#[rustc_mir(borrowck_graphviz_preflow="pre_two_phase.dot",
borrowck_graphviz_postflow="post_two_phase.dot")]
```
Includes doc for `FindPlaceUses`, as well as `Reservations` and
`ActiveBorrows` structs, which are wrappers are the `Borrows` struct
that dictate which flow analysis should be performed.
2017-12-01 12:32:51 +01:00
|
|
|
sets.gen(&ReserveOrActivateIndex::reserved(*index));
|
2017-12-20 18:15:33 +01:00
|
|
|
|
2018-03-05 02:44:10 -05:00
|
|
|
// Issue #46746: Two-phase borrows handles
|
|
|
|
// stmts of form `Tmp = &mut Borrow` ...
|
|
|
|
match lhs {
|
|
|
|
Place::Local(..) | Place::Static(..) => {} // okay
|
|
|
|
Place::Projection(..) => {
|
|
|
|
// ... can assign into projections,
|
|
|
|
// e.g. `box (&mut _)`. Current
|
|
|
|
// conservative solution: force
|
|
|
|
// immediate activation here.
|
|
|
|
sets.gen(&ReserveOrActivateIndex::active(*index));
|
2017-12-20 18:15:33 +01:00
|
|
|
}
|
|
|
|
}
|
2017-07-03 18:40:20 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-12-04 13:21:28 +02:00
|
|
|
mir::StatementKind::StorageDead(local) => {
|
|
|
|
// Make sure there are no remaining borrows for locals that
|
|
|
|
// are gone out of scope.
|
2018-03-05 02:44:10 -05:00
|
|
|
self.kill_borrows_on_local(sets, &local)
|
2017-12-04 13:21:28 +02:00
|
|
|
}
|
|
|
|
|
2017-12-23 23:45:07 +00:00
|
|
|
mir::StatementKind::InlineAsm { ref outputs, ref asm, .. } => {
|
|
|
|
for (output, kind) in outputs.iter().zip(&asm.outputs) {
|
|
|
|
if !kind.is_indirect && !kind.is_rw {
|
|
|
|
// Make sure there are no remaining borrows for direct
|
|
|
|
// output variables.
|
|
|
|
if let Place::Local(ref local) = *output {
|
|
|
|
// FIXME: Handle the case in which we're assigning over
|
|
|
|
// a projection (`foo.bar`).
|
2018-03-05 02:44:10 -05:00
|
|
|
self.kill_borrows_on_local(sets, local);
|
2017-12-23 23:45:07 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-07-03 18:40:20 +02:00
|
|
|
mir::StatementKind::SetDiscriminant { .. } |
|
|
|
|
mir::StatementKind::StorageLive(..) |
|
|
|
|
mir::StatementKind::Validate(..) |
|
2018-02-23 20:52:05 +00:00
|
|
|
mir::StatementKind::UserAssertTy(..) |
|
2017-07-03 18:40:20 +02:00
|
|
|
mir::StatementKind::Nop => {}
|
|
|
|
|
|
|
|
}
|
|
|
|
}
|
2017-10-30 08:28:07 -04:00
|
|
|
|
2018-03-06 03:37:21 -05:00
|
|
|
fn before_terminator_effect(&self,
|
|
|
|
sets: &mut BlockSets<ReserveOrActivateIndex>,
|
|
|
|
location: Location) {
|
2018-03-05 02:44:10 -05:00
|
|
|
debug!("Borrows::before_terminator_effect sets: {:?} location: {:?}", sets, location);
|
|
|
|
self.kill_loans_out_of_scope_at_location(sets, location);
|
2017-12-15 14:27:06 -06:00
|
|
|
}
|
|
|
|
|
2018-03-05 02:44:10 -05:00
|
|
|
fn terminator_effect(&self, sets: &mut BlockSets<ReserveOrActivateIndex>, location: Location) {
|
|
|
|
debug!("Borrows::terminator_effect sets: {:?} location: {:?}", sets, location);
|
|
|
|
|
2017-11-19 04:26:23 -08:00
|
|
|
let block = &self.mir.basic_blocks().get(location.block).unwrap_or_else(|| {
|
|
|
|
panic!("could not find block at location {:?}", location);
|
|
|
|
});
|
New `ActiveBorrows` dataflow for two-phase `&mut`; not yet borrowed-checked.
High-level picture: The old `Borrows` analysis is now called
`Reservations` (implemented as a newtype wrapper around `Borrows`);
this continues to compute whether a `Rvalue::Ref` can reach a
statement without an intervening `EndRegion`. In addition, we also
track what `Place` each such `Rvalue::Ref` was immediately assigned
to in a given borrow (yay for MIR-structural properties!).
The new `ActiveBorrows` analysis then tracks the initial use of any of
those assigned `Places` for a given borrow. I.e. a borrow becomes
"active" immediately after it starts being "used" in some way. (This
is conservative in the sense that we will treat a copy `x = y;` as a
use of `y`; in principle one might further delay activation in such
cases.)
The new `ActiveBorrows` analysis needs to take the `Reservations`
results as an initial input, because the reservation state influences
the gen/kill sets for `ActiveBorrows`. In particular, a use of `a`
activates a borrow `a = &b` if and only if there exists a path (in the
control flow graph) from the borrow to that use. So we need to know if
the borrow reaches a given use to know if it really gets a gen-bit or
not.
* Incorporating the output from one dataflow analysis into the input
of another required more changes to the infrastructure than I had
expected, and even after those changes, the resulting code is still
a bit subtle.
* In particular, Since we need to know the intrablock reservation
state, we need to dynamically update a bitvector for the
reservations as we are also trying to compute the gen/kills
bitvector for the active borrows.
* The way I ended up deciding to do this (after also toying with at
least two other designs) is to put both the reservation state and
the active borrow state into a single bitvector. That is why we now
have separate (but related) `BorrowIndex` and
`ReserveOrActivateIndex`: each borrow index maps to a pair of
neighboring reservation and activation indexes.
As noted above, these changes are solely adding the active borrows
dataflow analysis (and updating the existing code to cope with the
switch from `Borrows` to `Reservations`). The code to process the
bitvector in the borrow checker currently just skips over all of the
active borrow bits.
But atop this commit, one *can* observe the analysis results by
looking at the graphviz output, e.g. via
```rust
#[rustc_mir(borrowck_graphviz_preflow="pre_two_phase.dot",
borrowck_graphviz_postflow="post_two_phase.dot")]
```
Includes doc for `FindPlaceUses`, as well as `Reservations` and
`ActiveBorrows` structs, which are wrappers are the `Borrows` struct
that dictate which flow analysis should be performed.
2017-12-01 12:32:51 +01:00
|
|
|
|
|
|
|
let term = block.terminator();
|
2018-03-05 22:43:43 -05:00
|
|
|
self.perform_activations_at_location(sets, location);
|
|
|
|
self.kill_loans_out_of_scope_at_location(sets, location);
|
2018-03-05 02:44:10 -05:00
|
|
|
|
New `ActiveBorrows` dataflow for two-phase `&mut`; not yet borrowed-checked.
High-level picture: The old `Borrows` analysis is now called
`Reservations` (implemented as a newtype wrapper around `Borrows`);
this continues to compute whether a `Rvalue::Ref` can reach a
statement without an intervening `EndRegion`. In addition, we also
track what `Place` each such `Rvalue::Ref` was immediately assigned
to in a given borrow (yay for MIR-structural properties!).
The new `ActiveBorrows` analysis then tracks the initial use of any of
those assigned `Places` for a given borrow. I.e. a borrow becomes
"active" immediately after it starts being "used" in some way. (This
is conservative in the sense that we will treat a copy `x = y;` as a
use of `y`; in principle one might further delay activation in such
cases.)
The new `ActiveBorrows` analysis needs to take the `Reservations`
results as an initial input, because the reservation state influences
the gen/kill sets for `ActiveBorrows`. In particular, a use of `a`
activates a borrow `a = &b` if and only if there exists a path (in the
control flow graph) from the borrow to that use. So we need to know if
the borrow reaches a given use to know if it really gets a gen-bit or
not.
* Incorporating the output from one dataflow analysis into the input
of another required more changes to the infrastructure than I had
expected, and even after those changes, the resulting code is still
a bit subtle.
* In particular, Since we need to know the intrablock reservation
state, we need to dynamically update a bitvector for the
reservations as we are also trying to compute the gen/kills
bitvector for the active borrows.
* The way I ended up deciding to do this (after also toying with at
least two other designs) is to put both the reservation state and
the active borrow state into a single bitvector. That is why we now
have separate (but related) `BorrowIndex` and
`ReserveOrActivateIndex`: each borrow index maps to a pair of
neighboring reservation and activation indexes.
As noted above, these changes are solely adding the active borrows
dataflow analysis (and updating the existing code to cope with the
switch from `Borrows` to `Reservations`). The code to process the
bitvector in the borrow checker currently just skips over all of the
active borrow bits.
But atop this commit, one *can* observe the analysis results by
looking at the graphviz output, e.g. via
```rust
#[rustc_mir(borrowck_graphviz_preflow="pre_two_phase.dot",
borrowck_graphviz_postflow="post_two_phase.dot")]
```
Includes doc for `FindPlaceUses`, as well as `Reservations` and
`ActiveBorrows` structs, which are wrappers are the `Borrows` struct
that dictate which flow analysis should be performed.
2017-12-01 12:32:51 +01:00
|
|
|
|
|
|
|
match term.kind {
|
2017-11-19 04:26:23 -08:00
|
|
|
mir::TerminatorKind::Resume |
|
|
|
|
mir::TerminatorKind::Return |
|
|
|
|
mir::TerminatorKind::GeneratorDrop => {
|
|
|
|
// When we return from the function, then all `ReScope`-style regions
|
|
|
|
// are guaranteed to have ended.
|
|
|
|
// Normally, there would be `EndRegion` statements that come before,
|
|
|
|
// and hence most of these loans will already be dead -- but, in some cases
|
|
|
|
// like unwind paths, we do not always emit `EndRegion` statements, so we
|
|
|
|
// add some kills here as a "backup" and to avoid spurious error messages.
|
|
|
|
for (borrow_index, borrow_data) in self.borrows.iter_enumerated() {
|
2017-12-04 00:56:06 +02:00
|
|
|
if let ReScope(scope) = borrow_data.region {
|
|
|
|
// Check that the scope is not actually a scope from a function that is
|
|
|
|
// a parent of our closure. Note that the CallSite scope itself is
|
|
|
|
// *outside* of the closure, for some weird reason.
|
|
|
|
if let Some(root_scope) = self.root_scope {
|
|
|
|
if *scope != root_scope &&
|
|
|
|
self.scope_tree.is_subscope_of(*scope, root_scope)
|
|
|
|
{
|
New `ActiveBorrows` dataflow for two-phase `&mut`; not yet borrowed-checked.
High-level picture: The old `Borrows` analysis is now called
`Reservations` (implemented as a newtype wrapper around `Borrows`);
this continues to compute whether a `Rvalue::Ref` can reach a
statement without an intervening `EndRegion`. In addition, we also
track what `Place` each such `Rvalue::Ref` was immediately assigned
to in a given borrow (yay for MIR-structural properties!).
The new `ActiveBorrows` analysis then tracks the initial use of any of
those assigned `Places` for a given borrow. I.e. a borrow becomes
"active" immediately after it starts being "used" in some way. (This
is conservative in the sense that we will treat a copy `x = y;` as a
use of `y`; in principle one might further delay activation in such
cases.)
The new `ActiveBorrows` analysis needs to take the `Reservations`
results as an initial input, because the reservation state influences
the gen/kill sets for `ActiveBorrows`. In particular, a use of `a`
activates a borrow `a = &b` if and only if there exists a path (in the
control flow graph) from the borrow to that use. So we need to know if
the borrow reaches a given use to know if it really gets a gen-bit or
not.
* Incorporating the output from one dataflow analysis into the input
of another required more changes to the infrastructure than I had
expected, and even after those changes, the resulting code is still
a bit subtle.
* In particular, Since we need to know the intrablock reservation
state, we need to dynamically update a bitvector for the
reservations as we are also trying to compute the gen/kills
bitvector for the active borrows.
* The way I ended up deciding to do this (after also toying with at
least two other designs) is to put both the reservation state and
the active borrow state into a single bitvector. That is why we now
have separate (but related) `BorrowIndex` and
`ReserveOrActivateIndex`: each borrow index maps to a pair of
neighboring reservation and activation indexes.
As noted above, these changes are solely adding the active borrows
dataflow analysis (and updating the existing code to cope with the
switch from `Borrows` to `Reservations`). The code to process the
bitvector in the borrow checker currently just skips over all of the
active borrow bits.
But atop this commit, one *can* observe the analysis results by
looking at the graphviz output, e.g. via
```rust
#[rustc_mir(borrowck_graphviz_preflow="pre_two_phase.dot",
borrowck_graphviz_postflow="post_two_phase.dot")]
```
Includes doc for `FindPlaceUses`, as well as `Reservations` and
`ActiveBorrows` structs, which are wrappers are the `Borrows` struct
that dictate which flow analysis should be performed.
2017-12-01 12:32:51 +01:00
|
|
|
sets.kill(&ReserveOrActivateIndex::reserved(borrow_index));
|
2018-03-05 02:44:10 -05:00
|
|
|
sets.kill(&ReserveOrActivateIndex::active(borrow_index));
|
2017-12-04 00:56:06 +02:00
|
|
|
}
|
|
|
|
}
|
2017-11-19 04:26:23 -08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2017-12-19 01:17:16 +01:00
|
|
|
mir::TerminatorKind::Abort |
|
2017-11-19 04:26:23 -08:00
|
|
|
mir::TerminatorKind::SwitchInt {..} |
|
|
|
|
mir::TerminatorKind::Drop {..} |
|
|
|
|
mir::TerminatorKind::DropAndReplace {..} |
|
|
|
|
mir::TerminatorKind::Call {..} |
|
|
|
|
mir::TerminatorKind::Assert {..} |
|
|
|
|
mir::TerminatorKind::Yield {..} |
|
|
|
|
mir::TerminatorKind::Goto {..} |
|
|
|
|
mir::TerminatorKind::FalseEdges {..} |
|
2018-01-25 01:45:45 -05:00
|
|
|
mir::TerminatorKind::FalseUnwind {..} |
|
2017-11-19 04:26:23 -08:00
|
|
|
mir::TerminatorKind::Unreachable => {}
|
|
|
|
}
|
New `ActiveBorrows` dataflow for two-phase `&mut`; not yet borrowed-checked.
High-level picture: The old `Borrows` analysis is now called
`Reservations` (implemented as a newtype wrapper around `Borrows`);
this continues to compute whether a `Rvalue::Ref` can reach a
statement without an intervening `EndRegion`. In addition, we also
track what `Place` each such `Rvalue::Ref` was immediately assigned
to in a given borrow (yay for MIR-structural properties!).
The new `ActiveBorrows` analysis then tracks the initial use of any of
those assigned `Places` for a given borrow. I.e. a borrow becomes
"active" immediately after it starts being "used" in some way. (This
is conservative in the sense that we will treat a copy `x = y;` as a
use of `y`; in principle one might further delay activation in such
cases.)
The new `ActiveBorrows` analysis needs to take the `Reservations`
results as an initial input, because the reservation state influences
the gen/kill sets for `ActiveBorrows`. In particular, a use of `a`
activates a borrow `a = &b` if and only if there exists a path (in the
control flow graph) from the borrow to that use. So we need to know if
the borrow reaches a given use to know if it really gets a gen-bit or
not.
* Incorporating the output from one dataflow analysis into the input
of another required more changes to the infrastructure than I had
expected, and even after those changes, the resulting code is still
a bit subtle.
* In particular, Since we need to know the intrablock reservation
state, we need to dynamically update a bitvector for the
reservations as we are also trying to compute the gen/kills
bitvector for the active borrows.
* The way I ended up deciding to do this (after also toying with at
least two other designs) is to put both the reservation state and
the active borrow state into a single bitvector. That is why we now
have separate (but related) `BorrowIndex` and
`ReserveOrActivateIndex`: each borrow index maps to a pair of
neighboring reservation and activation indexes.
As noted above, these changes are solely adding the active borrows
dataflow analysis (and updating the existing code to cope with the
switch from `Borrows` to `Reservations`). The code to process the
bitvector in the borrow checker currently just skips over all of the
active borrow bits.
But atop this commit, one *can* observe the analysis results by
looking at the graphviz output, e.g. via
```rust
#[rustc_mir(borrowck_graphviz_preflow="pre_two_phase.dot",
borrowck_graphviz_postflow="post_two_phase.dot")]
```
Includes doc for `FindPlaceUses`, as well as `Reservations` and
`ActiveBorrows` structs, which are wrappers are the `Borrows` struct
that dictate which flow analysis should be performed.
2017-12-01 12:32:51 +01:00
|
|
|
}
|
2017-07-03 18:40:20 +02:00
|
|
|
|
|
|
|
fn propagate_call_return(&self,
|
New `ActiveBorrows` dataflow for two-phase `&mut`; not yet borrowed-checked.
High-level picture: The old `Borrows` analysis is now called
`Reservations` (implemented as a newtype wrapper around `Borrows`);
this continues to compute whether a `Rvalue::Ref` can reach a
statement without an intervening `EndRegion`. In addition, we also
track what `Place` each such `Rvalue::Ref` was immediately assigned
to in a given borrow (yay for MIR-structural properties!).
The new `ActiveBorrows` analysis then tracks the initial use of any of
those assigned `Places` for a given borrow. I.e. a borrow becomes
"active" immediately after it starts being "used" in some way. (This
is conservative in the sense that we will treat a copy `x = y;` as a
use of `y`; in principle one might further delay activation in such
cases.)
The new `ActiveBorrows` analysis needs to take the `Reservations`
results as an initial input, because the reservation state influences
the gen/kill sets for `ActiveBorrows`. In particular, a use of `a`
activates a borrow `a = &b` if and only if there exists a path (in the
control flow graph) from the borrow to that use. So we need to know if
the borrow reaches a given use to know if it really gets a gen-bit or
not.
* Incorporating the output from one dataflow analysis into the input
of another required more changes to the infrastructure than I had
expected, and even after those changes, the resulting code is still
a bit subtle.
* In particular, Since we need to know the intrablock reservation
state, we need to dynamically update a bitvector for the
reservations as we are also trying to compute the gen/kills
bitvector for the active borrows.
* The way I ended up deciding to do this (after also toying with at
least two other designs) is to put both the reservation state and
the active borrow state into a single bitvector. That is why we now
have separate (but related) `BorrowIndex` and
`ReserveOrActivateIndex`: each borrow index maps to a pair of
neighboring reservation and activation indexes.
As noted above, these changes are solely adding the active borrows
dataflow analysis (and updating the existing code to cope with the
switch from `Borrows` to `Reservations`). The code to process the
bitvector in the borrow checker currently just skips over all of the
active borrow bits.
But atop this commit, one *can* observe the analysis results by
looking at the graphviz output, e.g. via
```rust
#[rustc_mir(borrowck_graphviz_preflow="pre_two_phase.dot",
borrowck_graphviz_postflow="post_two_phase.dot")]
```
Includes doc for `FindPlaceUses`, as well as `Reservations` and
`ActiveBorrows` structs, which are wrappers are the `Borrows` struct
that dictate which flow analysis should be performed.
2017-12-01 12:32:51 +01:00
|
|
|
_in_out: &mut IdxSet<ReserveOrActivateIndex>,
|
2017-07-03 18:40:20 +02:00
|
|
|
_call_bb: mir::BasicBlock,
|
|
|
|
_dest_bb: mir::BasicBlock,
|
2017-12-01 14:39:51 +02:00
|
|
|
_dest_place: &mir::Place) {
|
New `ActiveBorrows` dataflow for two-phase `&mut`; not yet borrowed-checked.
High-level picture: The old `Borrows` analysis is now called
`Reservations` (implemented as a newtype wrapper around `Borrows`);
this continues to compute whether a `Rvalue::Ref` can reach a
statement without an intervening `EndRegion`. In addition, we also
track what `Place` each such `Rvalue::Ref` was immediately assigned
to in a given borrow (yay for MIR-structural properties!).
The new `ActiveBorrows` analysis then tracks the initial use of any of
those assigned `Places` for a given borrow. I.e. a borrow becomes
"active" immediately after it starts being "used" in some way. (This
is conservative in the sense that we will treat a copy `x = y;` as a
use of `y`; in principle one might further delay activation in such
cases.)
The new `ActiveBorrows` analysis needs to take the `Reservations`
results as an initial input, because the reservation state influences
the gen/kill sets for `ActiveBorrows`. In particular, a use of `a`
activates a borrow `a = &b` if and only if there exists a path (in the
control flow graph) from the borrow to that use. So we need to know if
the borrow reaches a given use to know if it really gets a gen-bit or
not.
* Incorporating the output from one dataflow analysis into the input
of another required more changes to the infrastructure than I had
expected, and even after those changes, the resulting code is still
a bit subtle.
* In particular, Since we need to know the intrablock reservation
state, we need to dynamically update a bitvector for the
reservations as we are also trying to compute the gen/kills
bitvector for the active borrows.
* The way I ended up deciding to do this (after also toying with at
least two other designs) is to put both the reservation state and
the active borrow state into a single bitvector. That is why we now
have separate (but related) `BorrowIndex` and
`ReserveOrActivateIndex`: each borrow index maps to a pair of
neighboring reservation and activation indexes.
As noted above, these changes are solely adding the active borrows
dataflow analysis (and updating the existing code to cope with the
switch from `Borrows` to `Reservations`). The code to process the
bitvector in the borrow checker currently just skips over all of the
active borrow bits.
But atop this commit, one *can* observe the analysis results by
looking at the graphviz output, e.g. via
```rust
#[rustc_mir(borrowck_graphviz_preflow="pre_two_phase.dot",
borrowck_graphviz_postflow="post_two_phase.dot")]
```
Includes doc for `FindPlaceUses`, as well as `Reservations` and
`ActiveBorrows` structs, which are wrappers are the `Borrows` struct
that dictate which flow analysis should be performed.
2017-12-01 12:32:51 +01:00
|
|
|
// there are no effects on borrows from method call return...
|
|
|
|
//
|
|
|
|
// ... but if overwriting a place can affect flow state, then
|
|
|
|
// latter is not true; see NOTE on Assign case in
|
|
|
|
// statement_effect_on_borrows.
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-03-05 02:44:10 -05:00
|
|
|
impl<'a, 'gcx, 'tcx> BitwiseOperator for Borrows<'a, 'gcx, 'tcx> {
|
New `ActiveBorrows` dataflow for two-phase `&mut`; not yet borrowed-checked.
High-level picture: The old `Borrows` analysis is now called
`Reservations` (implemented as a newtype wrapper around `Borrows`);
this continues to compute whether a `Rvalue::Ref` can reach a
statement without an intervening `EndRegion`. In addition, we also
track what `Place` each such `Rvalue::Ref` was immediately assigned
to in a given borrow (yay for MIR-structural properties!).
The new `ActiveBorrows` analysis then tracks the initial use of any of
those assigned `Places` for a given borrow. I.e. a borrow becomes
"active" immediately after it starts being "used" in some way. (This
is conservative in the sense that we will treat a copy `x = y;` as a
use of `y`; in principle one might further delay activation in such
cases.)
The new `ActiveBorrows` analysis needs to take the `Reservations`
results as an initial input, because the reservation state influences
the gen/kill sets for `ActiveBorrows`. In particular, a use of `a`
activates a borrow `a = &b` if and only if there exists a path (in the
control flow graph) from the borrow to that use. So we need to know if
the borrow reaches a given use to know if it really gets a gen-bit or
not.
* Incorporating the output from one dataflow analysis into the input
of another required more changes to the infrastructure than I had
expected, and even after those changes, the resulting code is still
a bit subtle.
* In particular, Since we need to know the intrablock reservation
state, we need to dynamically update a bitvector for the
reservations as we are also trying to compute the gen/kills
bitvector for the active borrows.
* The way I ended up deciding to do this (after also toying with at
least two other designs) is to put both the reservation state and
the active borrow state into a single bitvector. That is why we now
have separate (but related) `BorrowIndex` and
`ReserveOrActivateIndex`: each borrow index maps to a pair of
neighboring reservation and activation indexes.
As noted above, these changes are solely adding the active borrows
dataflow analysis (and updating the existing code to cope with the
switch from `Borrows` to `Reservations`). The code to process the
bitvector in the borrow checker currently just skips over all of the
active borrow bits.
But atop this commit, one *can* observe the analysis results by
looking at the graphviz output, e.g. via
```rust
#[rustc_mir(borrowck_graphviz_preflow="pre_two_phase.dot",
borrowck_graphviz_postflow="post_two_phase.dot")]
```
Includes doc for `FindPlaceUses`, as well as `Reservations` and
`ActiveBorrows` structs, which are wrappers are the `Borrows` struct
that dictate which flow analysis should be performed.
2017-12-01 12:32:51 +01:00
|
|
|
#[inline]
|
|
|
|
fn join(&self, pred1: usize, pred2: usize) -> usize {
|
|
|
|
pred1 | pred2 // union effects of preds when computing reservations
|
2017-07-03 18:40:20 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-03-05 02:44:10 -05:00
|
|
|
impl<'a, 'gcx, 'tcx> InitialFlow for Borrows<'a, 'gcx, 'tcx> {
|
2017-07-03 18:40:20 +02:00
|
|
|
#[inline]
|
|
|
|
fn bottom_value() -> bool {
|
2018-03-05 02:44:10 -05:00
|
|
|
false // bottom = nothing is reserved or activated yet
|
2017-07-03 18:40:20 +02:00
|
|
|
}
|
|
|
|
}
|
2017-11-16 15:32:13 -08:00
|
|
|
|
2017-12-01 14:39:51 +02:00
|
|
|
fn is_unsafe_place<'a, 'gcx: 'tcx, 'tcx: 'a>(
|
2017-11-16 15:32:13 -08:00
|
|
|
tcx: TyCtxt<'a, 'gcx, 'tcx>,
|
|
|
|
mir: &'a Mir<'tcx>,
|
2017-12-01 14:39:51 +02:00
|
|
|
place: &mir::Place<'tcx>
|
2017-11-16 15:32:13 -08:00
|
|
|
) -> bool {
|
2017-12-01 14:31:47 +02:00
|
|
|
use self::mir::Place::*;
|
2017-11-16 15:32:13 -08:00
|
|
|
use self::mir::ProjectionElem;
|
|
|
|
|
2017-12-01 14:39:51 +02:00
|
|
|
match *place {
|
2017-11-16 15:32:13 -08:00
|
|
|
Local(_) => false,
|
2018-01-16 09:31:48 +01:00
|
|
|
Static(ref static_) => tcx.is_static(static_.def_id) == Some(hir::Mutability::MutMutable),
|
2017-11-16 15:32:13 -08:00
|
|
|
Projection(ref proj) => {
|
|
|
|
match proj.elem {
|
|
|
|
ProjectionElem::Field(..) |
|
|
|
|
ProjectionElem::Downcast(..) |
|
|
|
|
ProjectionElem::Subslice { .. } |
|
|
|
|
ProjectionElem::ConstantIndex { .. } |
|
|
|
|
ProjectionElem::Index(_) => {
|
2017-12-01 14:39:51 +02:00
|
|
|
is_unsafe_place(tcx, mir, &proj.base)
|
2017-11-16 15:32:13 -08:00
|
|
|
}
|
|
|
|
ProjectionElem::Deref => {
|
|
|
|
let ty = proj.base.ty(mir, tcx).to_ty(tcx);
|
|
|
|
match ty.sty {
|
|
|
|
ty::TyRawPtr(..) => true,
|
2017-12-01 14:39:51 +02:00
|
|
|
_ => is_unsafe_place(tcx, mir, &proj.base),
|
2017-11-16 15:32:13 -08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|