First attempt at removing DropAndReplace #104488
Closed
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
|
(rustbot has picked a reviewer for you, use r? to override) |
rustbot
added
S-waiting-on-review
zeegomo
force-pushed
the
drop-elab
branch
3 times, most recently
from
8fdcab4
to
aec002f
Compare
This comment has been minimized.
This comment has been minimized.
|
r? @nikomatsakis since I think he wrote the MCP. |
|
☔ The latest upstream changes (presumably #103138) made this pull request unmergeable. Please resolve the merge conflicts. |
|
Figured out what the problem with the future size was. |
nikomatsakis
requested changes
Dec 28, 2022
| Some(Option::unwrap_or(unwind, resume_block)) | ||
| }, | ||
| is_replace, | ||
| }, |
There was a problem hiding this comment.
I don't follow this logic
There was a problem hiding this comment.
It's this case here
, will add a better comment
tmiasko
reviewed
Dec 28, 2022
|
Some changes occurred to MIR optimizations cc @rust-lang/wg-mir-opt Some changes occurred in src/tools/clippy cc @rust-lang/clippy This PR changes MIR cc @oli-obk, @RalfJung, @JakobDegen, @davidtwco, @celinval, @vakaras Some changes occurred to the CTFE / Miri engine cc @rust-lang/miri Some changes occurred in compiler/rustc_codegen_cranelift cc @bjorn3 |
This comment has been minimized.
This comment has been minimized.
RalfJung
reviewed
Jan 2, 2023
This comment has been minimized.
This comment has been minimized.
|
☔ The latest upstream changes (presumably #106472) made this pull request unmergeable. Please resolve the merge conflicts. |
zeegomo
force-pushed
the
drop-elab
branch
2 times, most recently
from
2303e04
to
54adf94
Compare
Aaron1011
reviewed
Jan 6, 2023
oli-obk
reviewed
Jan 9, 2023
This comment has been minimized.
This comment has been minimized.
* document is_replace field in Drop terminator * clarify drop and replace of untracked value
Add DesugaringKind::Replace to emit better diagnostic messages. At the moment it is used for drop and replaces and only the spans that actually contain a `Drop` terminator are marked as such. As there are no explicit drop correspondents in the HIR, marking happens during MIR build.
|
@oli-obk suggestion to use https://doc.rust-lang.org/nightly/nightly-rustc/rustc_span/struct.Span.html#method.mark_with_reason seems to be very promising. |
This comment has been minimized.
This comment has been minimized.
DesugaringKind::Replace is added at MIR build and does not show up in the HIR. Remove the desugaring from the span when walking down the HIR in diagnostic so that the span from the HIR correctly matches the span from MIR.
|
The job Click to see the possible cause of the failure (guessed by this bot) |
arielb1
reviewed
Jan 17, 2023
| location: Location, | ||
| ) { | ||
| if let mir::TerminatorKind::Drop { place, .. } = terminator.kind { |
There was a problem hiding this comment.
The variable shouldn't be considered initialized anymore but it's not handled by drop_flag_effects as it's not a move.
I think we can't rely on StorageDead because a drop could panic before reaching that location.
I discovered this problem in
rust/tests/ui/drop/repeat-drop.rs
Line 102 in c8e6a9e
The compiler moves
panic into a temp variable, but since the array it's zero sized, that variable never gets moved anywere and it's immediately dropped.
_8 = move _3; // scope 2 at tests/ui/drop/repeat-drop.rs:105:36: 105:41
drop(_8) -> [return: bb1, unwind: bb9];
bb9 (cleanup): {
drop(_8) -> bb10; // scope 2 at tests/ui/drop/repeat-drop.rs:105:44: 105:45
}
When this unwinds _8 is still considered initialized and drop elab does not remove the drop in bb9, which results in a double drop.
Now, not sure that this mir building is ideal (a panic in dropping a local shouldn't unwind to a block that drops the same local), but I think that what I said above about considering a variable uninitialized the moment it gets dropped still holds.
| location: Location, | ||
| ) { | ||
| if let mir::TerminatorKind::Drop { place, .. } = terminator.kind { |
arielb1
reviewed
Jan 20, 2023
| ) | ||
| }); | ||
| let source_info = this.source_info(span); | ||
| unpack!( |
There was a problem hiding this comment.
any reason you changed build_drop_and_replace to only include the sad path replace?
There was a problem hiding this comment.
Initially I removed all assigns and added the sad path one later. In the happy path you need the assign anyway at call site because you may not emit a replace if the type does not need a drop, so you can just add the assign regardless of whether you created a new block for a drop and replace or not.
Anyway, not a strong opinion, I'll revert to the original behavior
|
Switching to waiting on author until all comments are ticked ✔️ . Feel free to request a review with @rustbot author |
rustbot
added
S-waiting-on-author
|
☔ The latest upstream changes (presumably #107727) made this pull request unmergeable. Please resolve the merge conflicts. |
|
Going to close this for now and split into smaller chunks like #107271 |
Dylan-DPC
added a commit
to Dylan-DPC/rust
that referenced
this pull request
Feb 8, 2023
Treat Drop as a rmw operation
Previously, a Drop terminator was considered a move in MIR. This commit changes the behavior to only treat Drop as a mutable access to the dropped place.
In order for this change to be correct, we need to guarantee that
1. A dropped value won't be used again
2. Places that appear in a drop won't be used again before a
subsequent initialization.
We can ensure this to be correct at MIR construction because Drop will only be emitted when a variable goes out of scope, thus having:
* (1) as there is no way of reaching the old value. drop-elaboration
will also remove any uninitialized drop.
* (2) as the place can't be named following the end of the scope.
However, the initialization status, previously tracked by moves, should also be tied to the execution of a Drop, hence the additional logic in the dataflow analyses.
From discussion in [this thread](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/.60DROP.60.20to.20.60DROP_IF.60.20compiler-team.23558), originating from rust-lang/compiler-team#558.
See also rust-lang#104488 (comment)
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Feb 8, 2023
Treat Drop as a rmw operation
Previously, a Drop terminator was considered a move in MIR. This commit changes the behavior to only treat Drop as a mutable access to the dropped place.
In order for this change to be correct, we need to guarantee that
1. A dropped value won't be used again
2. Places that appear in a drop won't be used again before a
subsequent initialization.
We can ensure this to be correct at MIR construction because Drop will only be emitted when a variable goes out of scope, thus having:
* (1) as there is no way of reaching the old value. drop-elaboration
will also remove any uninitialized drop.
* (2) as the place can't be named following the end of the scope.
However, the initialization status, previously tracked by moves, should also be tied to the execution of a Drop, hence the additional logic in the dataflow analyses.
From discussion in [this thread](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/.60DROP.60.20to.20.60DROP_IF.60.20compiler-team.23558), originating from rust-lang/compiler-team#558.
See also rust-lang#104488 (comment)
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Feb 8, 2023
Treat Drop as a rmw operation
Previously, a Drop terminator was considered a move in MIR. This commit changes the behavior to only treat Drop as a mutable access to the dropped place.
In order for this change to be correct, we need to guarantee that
1. A dropped value won't be used again
2. Places that appear in a drop won't be used again before a
subsequent initialization.
We can ensure this to be correct at MIR construction because Drop will only be emitted when a variable goes out of scope, thus having:
* (1) as there is no way of reaching the old value. drop-elaboration
will also remove any uninitialized drop.
* (2) as the place can't be named following the end of the scope.
However, the initialization status, previously tracked by moves, should also be tied to the execution of a Drop, hence the additional logic in the dataflow analyses.
From discussion in [this thread](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/.60DROP.60.20to.20.60DROP_IF.60.20compiler-team.23558), originating from rust-lang/compiler-team#558.
See also rust-lang#104488 (comment)
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Mar 5, 2023
Desugaring of drop and replace at MIR build This commit desugars the drop and replace deriving from an assignment at MIR build, avoiding the construction of the `DropAndReplace` terminator (which will be removed in a following PR). In order to retain the same error messages for replaces a new `DesugaringKind::Replace` variant is introduced. The changes in the borrowck are also useful for future work in moving drop elaboration before borrowck, as no `DropAndReplace` would be present there anymore. Notes on test diffs: * `tests/ui/borrowck/issue-58776-borrowck-scans-children`: the assignment deriving from the desugaring kills the borrow. * `tests/ui/async-await/async-fn-size-uninit-locals.rs`, `tests/mir-opt/issue_41110.test.ElaborateDrops.after.mir`, `tests/mir-opt/issue_41888.main.ElaborateDrops.after.mir`: drop elaboration generates (or reads from) a useless drop flag due to an issue with the dataflow analysis. Will be fixed independently by rust-lang#106430. See rust-lang#104488 for more context
saethlin
pushed a commit
to saethlin/miri
that referenced
this pull request
Mar 5, 2023
Desugaring of drop and replace at MIR build This commit desugars the drop and replace deriving from an assignment at MIR build, avoiding the construction of the `DropAndReplace` terminator (which will be removed in a following PR). In order to retain the same error messages for replaces a new `DesugaringKind::Replace` variant is introduced. The changes in the borrowck are also useful for future work in moving drop elaboration before borrowck, as no `DropAndReplace` would be present there anymore. Notes on test diffs: * `tests/ui/borrowck/issue-58776-borrowck-scans-children`: the assignment deriving from the desugaring kills the borrow. * `tests/ui/async-await/async-fn-size-uninit-locals.rs`, `tests/mir-opt/issue_41110.test.ElaborateDrops.after.mir`, `tests/mir-opt/issue_41888.main.ElaborateDrops.after.mir`: drop elaboration generates (or reads from) a useless drop flag due to an issue with the dataflow analysis. Will be fixed independently by rust-lang/rust#106430. See rust-lang/rust#104488 for more context
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.
First attempt at removing the
DropAndReplaceterminator which complicates things a bit in some cases.Based on zulip/drop-to-drop-if
Eventually, I re-introduced a flag in the
Dropterminator to indicate whether this drop is from a drop and replace operation. This is used mainly for better diagnostic and to check some invariants.Failing UI Tests
Diagnostic underline whole assignment instead of just the left value
ex:
[ui] src/test/ui/borrowck/borrowck-field-sensitivity.rs
[ui] src/test/ui/borrowck/borrowck-issue-48962.rs
[ui] src/test/ui/borrowck/borrowck-loan-of-static-data-issue-27616.rs
[ui] src/test/ui/borrowck/borrowck-partial-reinit-1.rs
[ui] src/test/ui/borrowck/borrowck-partial-reinit-2.rs
[ui] src/test/ui/borrowck/borrowck-partial-reinit-4.rs
[ui] src/test/ui/borrowck/borrowck-vec-pattern-nesting.rs
[ui] src/test/ui/borrowck/index-mut-help.rs
[ui] src/test/ui/borrowck/issue-45199.rs
[ui] src/test/ui/c-variadic/variadic-ffi-4.rs
[ui] src/test/ui/closures/2229_closure_analysis/diagnostics/box.rs
[ui] src/test/ui/liveness/liveness-assign/liveness-assign-imm-local-with-drop.rs
[ui] src/test/ui/nll/issue-27868.rs
[ui] src/test/ui/object-lifetime/object-lifetime-default-from-box-error.rs
[ui] src/test/ui/regions/regions-infer-paramd-indirect.rs
[ui] src/test/ui/unboxed-closures/unboxed-closures-failed-recursive-fn-1.rs
Replace kills loans on previous value
destructured assignment from drop and replace now kills loans. I don't think it's too big of an issue as the assignment should already trigger the borrowck, but the compiler now reports fewer errors in some cases
[ui] src/test/ui/borrowck/issue-58776-borrowck-scans-children.rs
Also fixes #70919 but I didn't add any regression tests for it, might borrow them from #102078 in a separate PR once this lands