See #48431 for discussion as to why this was necessary and what we hoped to
accomplish. A brief summary:
- the first implementation of 2-phase borrows was hard to limit in the way we
wanted. That is, it was too good at accepting all 2-phase borrows rather than
just autorefs =)
- Numerous diagnostic regressions were introduced by 2-phase borrow support
which were difficult to fix
The new output format is perhaps a little more readable. As a bonus, we get
labels on the outgoing edges to more easily corroborate the dataflow with the
plain MIR graphviz output.
[NLL] Add false edges out of infinite loops
Resolves#46036 by adding a `cleanup` member to the `FalseEdges` terminator kind. There's also a small doc fix to one of the other comments in `into.rs` which I can pull out in to another PR if desired =)
This PR should pass CI but the test suite has been relatively unstable on my system so I'm not 100% sure.
r? @nikomatsakis
Sometimes a simple goto misses the cleanup/unwind edges. Specifically, in the
case of infinite loops such as those introduced by a loop statement without any
other out edges. Analogous to TerminatorKind::FalseEdges; this new terminator
kind is used when we want borrowck to consider an unwind path, but real control
flow should never actually take it.
is_unsafe_place only filters out statics in the rhs, not the lhs. Since
it's possible to reach that 'Place::Static', we handle statics the same
way as we do locals.
Fixes#47789
NLL fixes
First, introduce pre-statement effects to dataflow to fix#46875. Edge dataflow effects might make that redundant, but I'm not sure of the best way to integrate them with liveness etc., and if this is a hack, this is one of the cleanest hacks I've seen.
And I want a small fix to avoid the torrent of bug reports.
Second, fix linking of projections to fix#46974
r? @pnkfelix
[MIR Borrowck] Moveck inline asm statements
Closes#45695
New behavior:
* Input operands to `asm!` are moved, direct output operands are initialized.
* Direct, non-read-write outputs match the assignment changes in #46752 (Shallow writes, end borrows).
Prevent unwinding past FFI boundaries
Second attempt to write a patch to solve this.
r? @nikomatsakis
~~So, my biggest issue with this patch is the way the patch determines *what* functions should have an abort landing pad (in `construct_fn`). I would ideally have this code match [src/librustc_trans/callee.rs::get_fn](https://github.com/rust-lang/rust/blob/master/src/librustc_trans/callee.rs#L107-L115) but couldn't find an id that returns true for `is_foreign_item`. Also tried `tcx.has_attr("unwind")` with no luck.~~ FIXED
Other issues:
* llvm.trap is an SIGILL on amd64. Ideally we could use panic-abort's version of aborting which is nicer but we don't want to depend on that library...
* ~~Mir inlining is a stub currently.~~ FIXED (no-op)
Also, when reviewing please take into account that I'm new to the code and only partially know what I'm doing... and that I've mostly made made matches on `TerminatorKind::Abort` match either `TerminatorKind::Resume` or `TerminatorKind::Unreachable` based on what looked best.
Ensure separate activations only occur for assignments to locals
Ensure separate activations only occur for assignments to locals, not projections.
Fix#46746.
(I didn't make a regression test because we do not really have a good way to directly express the case that we are trying to catch, because we cannot write MIR directly.)
Split PlaceContext::Store into Store & AsmOutput
Outputs in InlineAsm can be read-write, so splitting it out is useful for things like Store-Store folding, as that's unsound for a Store-AsmOutput.
This PR is intended to make no changes, just be the mechanical split of the enum. Future changes can use the split, like a MIR pass I'm working on and perhaps two-phase borrows (see this FIXME: https://github.com/rust-lang/rust/pull/46852/files#diff-74dcd7740ab2104cd2b9a3b68dd4f208R543)
Outputs in InlineAsm can be read-write, so splitting it out is useful for things like Store-Store folding, as it cannot be done for a Store-AsmOutput.
This PR is intended to make no changes, just be the mechanical split of the enum. Future changes can use the split, like a MIR pass I'm working on and perhaps two-phase borrows.
Instead we are "just" careful to invoke it (which sets up a bunch of kill bits)
before we go into the code that sets up the gen bits.
That way, when the gen bits are set up, they will override any
previously set kill-bits for those reservations or activations.
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.
This is meant to ease development of multi-stage dataflow analyses
where the output from one analysis is used to initialize the state
for the next; in such a context, you cannot start with `bottom_value`
for all the bits.
If the gen/kill bits are set there, the effects of `start_block_effects`
will not be seen when using `FlowAtLocation` etc. to go over the MIR.
EverInitializedLvals is the only pass that got this wrong, but this
fixes the footgun for everyone.
