Fix spurious error when a Drop local has an assignment in a loop

[Aaron1011]

Fixes #70919

DropAndReplace terminators are special - unlike all other terminators, they perform two distinct actions (a drop and a store) to the same Place. This complicates various analysis passes that we do, which expect at most one of 'Drop'/'Def'/'Use' for a local at a given MIR location.

Previously, we categorized a DropAndReplace terminator's Local access as MutatingUseContext::Drop. As a result, livness computation would not consider the DropAndReplace as a store ('Def') of a local. The "use live" set would end up being too large (a use would be seen to extend back to an earlier store, rather than the closure DropAndReplace).

We now explicitly propagate information about DropAndReplace terminators via new enum variants MutatingUseContext:DropAndReplace and DefUse::DropAndReplace. We use this information in liveness computation to record both a Drop and a Def. This prevents creating an extra-large "use live" set, while ensuring that te local is still considered "drop live" at the required locations.

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[rust-highfive]

r? @nagisa

(rust-highfive has picked a reviewer for you, use r? to override)

[pnkfelix]

@bors r+

[bors]

📌 Commit ba8d1eb689dea77b153b0ebb20bfc3d6eceb338a has been approved by pnkfelix

It is now in the queue for this repository.

[tmiasko]

@bors r-

[Aaron1011]

@tmiasko Updated

[tmiasko]

@bors r=pnkfelix,tmiasko

[bors]

📌 Commit 3bb8c22 has been approved by pnkfelix,tmiasko

It is now in the queue for this repository.

[nagisa]

r? @pnkfelix

[Aaron1011]

After doing additional testing, I've found that this PR has an odd effect on this code:

struct HasDrop<T>(T);
impl<T> Drop for HasDrop<T> {
    fn drop(&mut self) {}
}

#[allow(unused_assignments)]
#[allow(unused_variables)]
fn foo() {
    let mut first: u8 = 0;
    let mut has_drop = Some(HasDrop(&first));

    loop {
        match true {
            true => {
                has_drop = Some(HasDrop(&first));
            }
            false => {
                drop(has_drop);
                has_drop = None;
                let reborrow = &mut first;
            }
        }
        
    }
}

fn main() {}

It compiles, but only if you have both drop(has_drop) and hash_drop = None. I think the handling of DropAndReplace in ConstraintGeneration is doing something odd (it doesn't go through visit_local).

I'm getting worried that this change is actually unsound in some subtle way. If I can't figure out a simpler way of doing this, then I think we should try to get rid of DropAndReplace entirely, as discussed in https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/.60DROP.60.20to.20.60DROP_IF.60.20compiler-team.23558.

[Aaron1011]

@bors r-

[bors]

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