Enable support for IndirectlyMutableLocals in rustc_peek
#64980
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We now use `DataflowResultsCursor` to get the dataflow state before calls to `rustc_peek`. The original version used a custom implementation that only looked at assignment statements. This also extends `rustc_peek` to take arguments by-value as well as by-reference, and allows *all* dataflow analyses, not just those dependent on `MoveData`, to be inspected.
rust-highfive
added
the
S-waiting-on-review
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
ecstatic-morse
force-pushed
the
better-rustc-peek
branch
from
71e1bd7
to
33aa5e8
Compare
|
Please open an issue about the bug in the @bors r+ |
|
📌 Commit 33aa5e8 has been approved by |
bors
added
S-waiting-on-bors
Centril
added a commit
to Centril/rust
that referenced
this pull request
Oct 2, 2019
…=oli-obk Enable support for `IndirectlyMutableLocals` in `rustc_peek` This PR allows `rustc_peek` tests to be written for the `IndirectlyMutableLocals` analysis implemented in rust-lang#64470. See any of the tests in [`test/ui/mir-dataflow`](https://github.com/rust-lang/rust/blob/master/src/test/ui/mir-dataflow/inits-1.rs) for an example. Included in this PR is a major rewrite of the `rustc_peek` module. This was motivated by the differences between the `IndirectlyMutableLocals` analysis and the initialized places ones. To properly test `IndirectlyMutableLocals`, we must pass locals by-value to `rustc_peek`, since any local that is not `Freeze` will be marked as indirectly mutable as soon as a reference to it is taken. Unfortunately, `UnsafeCell` is not `Copy`, so we can only do one `rustc_peek` on each value with interior mutability inside a test. I'm not sure how to deal with this restriction; perhaps I need to special case borrows preceding a call to `rustc_peek` in the analysis itself? `rustc_peek` also assumed that the analysis was done on move paths and that its transfer function only needed to be applied at assignment statements. This PR removes both of those restrictions by adding a trait, `RustcPeekAt`, that controls how the peeked at `Place` maps to the current dataflow state and using a dataflow cursor to retrieve the state itself. Finally, this PR adds a test which demonstrates some unsoundness in the `IndirectlyMutableLocals` analysis by converting a reference to a `Freeze` field to a reference to a `!Freeze` field by offsetting a pointer (or in this case transmuting a pointer to a ZST field with the same address as a `!Freeze` field). This does not represent a hole in the language proper, since this analysis is only used to validate `const` bodies, in which the unsound code will only compile with `-Zunleash-the-miri-inside-of-you`. Nevertheless, this should get fixed. r? @oli-obk
bors
added a commit
that referenced
this pull request
Oct 2, 2019
Rollup of 13 pull requests Successful merges: - #64581 (Fix unreachable_code warnings for try{} block ok-wrapped expressions) - #64850 (Remove inlines from DepNode code) - #64914 (regression test for 64453 borrow check error.) - #64922 (Use PlaceBuilder to avoid a lot of slice -> vec -> slice convertions) - #64948 (Improve sidebar styling to make its integration easier) - #64961 (Make comment about dummy type a bit more clear) - #64967 (Don't mark borrows of zero-sized arrays as indirectly mutable) - #64973 (Fix typo while setting `compile-flags` in test) - #64980 (Enable support for `IndirectlyMutableLocals` in `rustc_peek` ) - #64989 (Fix ICE #64964) - #64991 ([const-prop] Correctly handle locals that can't be propagated) - #64995 (Remove rustdoc warning) - #64997 (rustc book: nitpick SLP vectorization) Failed merges: r? @ghost
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR allows
rustc_peektests to be written for theIndirectlyMutableLocalsanalysis implemented in #64470. See any of the tests intest/ui/mir-dataflowfor an example.Included in this PR is a major rewrite of the
rustc_peekmodule. This was motivated by the differences between theIndirectlyMutableLocalsanalysis and the initialized places ones.To properly test
IndirectlyMutableLocals, we must pass locals by-value torustc_peek, since any local that is notFreezewill be marked as indirectly mutable as soon as a reference to it is taken. Unfortunately,UnsafeCellis notCopy, so we can only do onerustc_peekon each value with interior mutability inside a test. I'm not sure how to deal with this restriction; perhaps I need to special case borrows preceding a call torustc_peekin the analysis itself?rustc_peekalso assumed that the analysis was done on move paths and that its transfer function only needed to be applied at assignment statements. This PR removes both of those restrictions by adding a trait,RustcPeekAt, that controls how the peeked atPlacemaps to the current dataflow state and using a dataflow cursor to retrieve the state itself.Finally, this PR adds a test which demonstrates some unsoundness in the
IndirectlyMutableLocalsanalysis by converting a reference to aFreezefield to a reference to a!Freezefield by offsetting a pointer (or in this case transmuting a pointer to a ZST field with the same address as a!Freezefield). This does not represent a hole in the language proper, since this analysis is only used to validateconstbodies, in which the unsound code will only compile with-Zunleash-the-miri-inside-of-you. Nevertheless, this should get fixed.r? @oli-obk