Desugaring of drop and replace at MIR build #107844

zeegomo · 2023-02-09T12:09:09Z

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 Remove dead unwinds before drop elaboration #106430.

See #104488 for more context

rustbot · 2023-02-09T12:09:18Z

r? @lcnr

(rustbot has picked a reviewer for you, use r? to override)

rustbot · 2023-02-09T12:09:22Z

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

compiler/rustc_borrowck/src/diagnostics/mod.rs

lcnr · 2023-02-10T09:29:49Z

r? compiler

cjgillot · 2023-02-10T22:41:47Z

compiler/rustc_borrowck/src/lib.rs

-                                Some(kind),
-                            ),
+                        WriteKind::StorageDeadOrDrop => {
+                            if let Some(DesugaringKind::Replace) = place_span.1.desugaring_kind() {


This may deserve a helper function. The fact that checking desugaring_kind() is enough comes from the fact that DesugaringKind::Replace can only be created after the other (HIR-based) variants.

cjgillot · 2023-02-10T22:46:07Z

compiler/rustc_mir_build/src/build/scope.rs

+
+        // create the new block for the assignment in the case of unwinding
+        let assign_unwind = self.cfg.start_new_cleanup_block();
+        self.cfg.push_assign(assign_unwind, source_info, place, value.clone());


Having the assignment even in the unwind case is a bit surprising. This is the current behaviour, so ok. Should eventually be removed in the future?

As long as drop can unwind, it is necessary to avoid leaving partially destroyed places behind. See #30380 for an example.

cjgillot · 2023-02-10T22:48:08Z

tests/ui/borrowck/borrowck-vec-pattern-nesting.rs

@@ -8,6 +8,7 @@ fn a() {
        //~^ NOTE `vec[_]` is borrowed here
            vec[0] = Box::new(4); //~ ERROR cannot assign
            //~^ NOTE `vec[_]` is assigned to here
+            //~| NOTE in this expansion of desugaring of drop and replace


Should DesugaringKind::Replace be filtered out from diagnostic notes?

It's not shown in human readable output but only in json, like other desugarings (for, ?, ...). I think it makes sense they all have the same behavior

eholk · 2023-02-18T00:43:49Z

compiler/rustc_mir_build/src/build/expr/stmt.rs

@@ -40,7 +40,7 @@ impl<'a, 'tcx> Builder<'a, 'tcx> {
                // Generate better code for things that don't need to be
                // dropped.
                if lhs.ty.needs_drop(this.tcx, this.param_env) {
-                    let rhs = unpack!(block = this.as_local_operand(block, rhs));
+                    let rhs = unpack!(block = this.as_local_rvalue(block, rhs));


It's a little surprising to me that this wasn't .as_local_rvalue already. Were we just less precise than we could be before?

Oh no, I guess this change is because build_drop_and_replace was changed to take an rvalue.

tests/ui/async-await/async-fn-size-uninit-locals.rs

eholk · 2023-02-18T01:09:26Z

This looks pretty good to me. I'm a little curious about why the futures got bigger in async-fn-size-uninit-locals.rs, but it's only one byte so I don't think it's a blocker.

I'd feel better letting someone else do the final signoff though. Maybe @cjgillot?

@bors r? @cjgillot

cjgillot

Could you make the ElaborateDrops tests output ElaborateDrops.diff instead of ElaborateDrops.after.mir? It will be easier to check the output.

compiler/rustc_mir_build/src/build/scope.rs

tests/mir-opt/issue_41110.test.ElaborateDrops.after.mir

cjgillot · 2023-02-19T16:37:29Z

compiler/rustc_mir_transform/src/elaborate_drops.rs

+                            // A drop and replace behind a pointer/array/whatever.
+                            // The borrow checker requires that these locations are initialized before the assignment,
+                            // so we just leave an unconditional drop.
+                            assert!(!data.is_cleanup);


I'm not sure I have a clear idea of MIR looks like in that case. Do you have an example?

fn replace(c: &mut String) { *c = "new".to_string(); } fn main() { let mut c = "old".to_string(); replace(&mut c); }

the body of replace gets translated to something like:

bb1: { _2 = <something that builds the new string>; drop((*_1)) -> [return: bb3, unwind: bb2]; } bb2 (cleanup): { (*_1) = move _2; resume; } bb3: { (*_1) = move _2; return; }

Under normal conditions, dropping something behind a pointer would be bad (drop((*_1))), but in a drop and replace it's fine because it's always initialized before any other use.
assert!(!data.is_cleanup) is there because a drop and replace is never emitted in the unwind path so it shouldn't be possible to hit this branch.

In that case, should we assert that we will assign to *_1 starting both target and unwind bbs? Just to future-proof against changes to MIR building.

That's what the check for DesugaringKind::Replace is for.
Alternatively we could check for assignments, but it could be that some unrelated code is inserted before those that does not access that variable and is therefore valid but breaks the check.
For this reason I was kind of considering DesugaringKind::Replace as a guarantee that there will be an assignment later to the same place that is compliant with the semantics of a replace, without having to know exactly how the desugaring is done.
However, I don't see any reason why we should insert stuff between the drop and the assignment for now, so if you think it's safer that way it's quite easy to do. I 'm just worrying it might be a bit sensitive to reorderings in the MIR

tests/mir-opt/basic_assignment.main.SimplifyCfg-initial.after.mir

zeegomo · 2023-02-23T17:48:40Z

Once #106430 is merged I'll rebase this PR on top of that to make reviewing easier

bors · 2023-02-25T09:58:38Z

☔ The latest upstream changes (presumably #106430) made this pull request unmergeable. Please resolve the merge conflicts.

zeegomo · 2023-02-27T20:51:51Z

@rustbot label -S-waiting-on-author +S-waiting-on-review

zeegomo · 2023-03-03T17:23:01Z

I've looked at the failure and it seems like the code for generating coverage spans for closure signatures is a bit fragile.
As far as I understand this PR changes MIR in a way such that the unstable sort in

rust/compiler/rustc_mir_transform/src/coverage/spans.rs

Line 338 in 13471d3

initial_spans.sort_unstable_by(|a, b| {

now reorders two statements with the same span the other way around and this messes with later processing.
Changing it to a stable sort fixes this issue and also add coverage info in other closure sigs where it was missing before (presumably because of the same problem).

Since it looks like we are fine with some closures sigs not having coverage info and changing to a stable sort could have perf implications, I would go ahead with this for now (changed the expected output) and deal with this problem in a separate PR

cjgillot · 2023-03-03T18:10:45Z

@bors r+

bors · 2023-03-03T18:10:48Z

📌 Commit d1f7fa5 has been approved by cjgillot

It is now in the queue for this repository.

matthiaskrgr · 2023-03-04T21:38:14Z

@bors rollup=never let's get this out of the queue

bors · 2023-03-05T07:56:29Z

⌛ Testing commit d1f7fa5 with merge 14c54b6...

bors · 2023-03-05T10:36:55Z

☀️ Test successful - checks-actions
Approved by: cjgillot
Pushing 14c54b6 to master...

rust-timer · 2023-03-05T12:19:03Z

Finished benchmarking commit (14c54b6): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-1.0%	[-1.1%, -1.0%]	2
Improvements ✅ (secondary)	-2.0%	[-2.6%, -0.3%]	7
All ❌✅ (primary)	-1.0%	[-1.1%, -1.0%]	2

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.9%	[0.9%, 0.9%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.9%	[0.9%, 0.9%]	1

Cycles

This benchmark run did not return any relevant results for this metric.

Desugaring DropAndReplace at MIR build (rust-lang#107844) fixed issue 70919. Add regressions tests, borrowed from rust-lang#102078, to ensure we check for this in the future. Co-authored-by: Aaron Hill <aa1ronham@gmail.com>

Add regression tests for issue 70919 Desugaring DropAndReplace at MIR build (rust-lang#107844) fixed rust-lang#70919. Add regressions tests, borrowed from rust-lang#102078, to ensure we check for this in the future. cc `@Aaron1011`

Add regression tests for issue 70919 Desugaring DropAndReplace at MIR build (rust-lang#107844) fixed rust-lang#70919. Add regressions tests, borrowed from rust-lang#102078, to ensure we check for this in the future. cc ``@Aaron1011``

…asko Remove DropAndReplace terminator rust-lang#107844 made DropAndReplace unused, let's remove it completely from the codebase.

ChayimFriedman2 · 2023-03-10T04:30:08Z

This PR made the following code compile:

struct Foo<'a> {
    v: &'a mut (),
}

impl Drop for Foo<'_> {
    fn drop(&mut self) {}
}

fn bar() {
    let mut v = ();
    let mut x = Foo { v: &mut v };
    drop(x);
    x = Foo { v: &mut v };
}

I didn't see an FCP, so I'm noting.

…asko Remove DropAndReplace terminator rust-lang#107844 made DropAndReplace unused, let's remove it completely from the codebase.

We previously had to use an atomic to work around a Rust compiler bug. However, now that rust-lang/rust#107844 is fixed, this can just be `FnMut`.

rustbot assigned lcnr Feb 9, 2023

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Feb 9, 2023

kadiwa4 reviewed Feb 9, 2023

View reviewed changes

compiler/rustc_borrowck/src/diagnostics/mod.rs Outdated Show resolved Hide resolved

zeegomo force-pushed the no-drop-and-rep branch from b31b11b to d809b3f Compare February 9, 2023 21:56

rustbot assigned eholk and unassigned lcnr Feb 10, 2023

cjgillot reviewed Feb 10, 2023

View reviewed changes

eholk reviewed Feb 18, 2023

View reviewed changes

tests/ui/async-await/async-fn-size-uninit-locals.rs Outdated Show resolved Hide resolved

eholk approved these changes Feb 18, 2023

View reviewed changes

rustbot assigned cjgillot and unassigned eholk Feb 18, 2023

cjgillot reviewed Feb 19, 2023

View reviewed changes

compiler/rustc_mir_build/src/build/scope.rs Outdated Show resolved Hide resolved

tests/mir-opt/issue_41110.test.ElaborateDrops.after.mir Outdated Show resolved Hide resolved

cjgillot reviewed Feb 19, 2023

View reviewed changes

tests/mir-opt/basic_assignment.main.SimplifyCfg-initial.after.mir Show resolved Hide resolved

zeegomo force-pushed the no-drop-and-rep branch from 0224acf to e9acc52 Compare February 23, 2023 13:41

cjgillot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 25, 2023

zeegomo force-pushed the no-drop-and-rep branch from e9acc52 to d8d8287 Compare February 26, 2023 00:23

zeegomo requested a review from cjgillot February 26, 2023 16:48

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Feb 27, 2023

zeegomo added 2 commits March 3, 2023 16:33

Add needs-unwind

f605e90

Update expected closure coverage info in test

d1f7fa5

zeegomo force-pushed the no-drop-and-rep branch from ee5de4c to d1f7fa5 Compare March 3, 2023 17:22

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 3, 2023

bors added the merged-by-bors This PR was explicitly merged by bors. label Mar 5, 2023

bors merged commit 14c54b6 into rust-lang:master Mar 5, 2023

rustbot added this to the 1.70.0 milestone Mar 5, 2023

zeegomo mentioned this pull request Mar 5, 2023

Add regression tests for issue 70919 #108780

Merged

WaffleLapkin mentioned this pull request Mar 6, 2023

Moved value with drop gets borrowed on reassignment #82656

Closed

zeegomo mentioned this pull request Mar 7, 2023

Remove DropAndReplace terminator #108856

Merged

cjgillot mentioned this pull request Jul 9, 2023

Removing DropAndReplace MIR allowed more code to compile #113501

Open

2 tasks

sunshowers mentioned this pull request Jul 29, 2023

[update-engine] stop using atomics now that we're on Rust 1.70 oxidecomputer/omicron#3796

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Desugaring of drop and replace at MIR build #107844

Desugaring of drop and replace at MIR build #107844

zeegomo commented Feb 9, 2023 •

edited

Loading

rustbot commented Feb 9, 2023

rustbot commented Feb 9, 2023

lcnr commented Feb 10, 2023

cjgillot Feb 10, 2023

cjgillot Feb 10, 2023

tmiasko Feb 11, 2023

cjgillot Feb 10, 2023

zeegomo Feb 11, 2023

eholk Feb 18, 2023

eholk Feb 18, 2023

eholk commented Feb 18, 2023

cjgillot left a comment

cjgillot Feb 19, 2023

zeegomo Feb 23, 2023 •

edited

Loading

cjgillot Feb 23, 2023

zeegomo Feb 23, 2023

zeegomo commented Feb 23, 2023

bors commented Feb 25, 2023

zeegomo commented Feb 27, 2023

zeegomo commented Mar 3, 2023

cjgillot commented Mar 3, 2023

bors commented Mar 3, 2023

matthiaskrgr commented Mar 4, 2023

bors commented Mar 5, 2023

bors commented Mar 5, 2023

rust-timer commented Mar 5, 2023

ChayimFriedman2 commented Mar 10, 2023

Desugaring of drop and replace at MIR build #107844

Desugaring of drop and replace at MIR build #107844

Conversation

zeegomo commented Feb 9, 2023 • edited Loading

rustbot commented Feb 9, 2023

rustbot commented Feb 9, 2023

lcnr commented Feb 10, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

eholk commented Feb 18, 2023

cjgillot left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zeegomo Feb 23, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zeegomo commented Feb 23, 2023

bors commented Feb 25, 2023

zeegomo commented Feb 27, 2023

zeegomo commented Mar 3, 2023

cjgillot commented Mar 3, 2023

bors commented Mar 3, 2023

matthiaskrgr commented Mar 4, 2023

bors commented Mar 5, 2023

bors commented Mar 5, 2023

rust-timer commented Mar 5, 2023

Overall result: ✅ improvements - no action needed

ChayimFriedman2 commented Mar 10, 2023

zeegomo commented Feb 9, 2023 •

edited

Loading

zeegomo Feb 23, 2023 •

edited

Loading