Fix projections when parent capture is by-ref but child capture is by-value in the ByMoveBody pass

[compiler-errors]

This fixes a somewhat strange bug where we build the incorrect MIR in #129074. This one is weird, but I don't expect it to actually matter in practice since it almost certainly results in a move error in borrowck. However, let's not ICE.

Given the code:

#![feature(async_closure)]

// NOT copy.
struct Ty;

fn hello(x: &Ty) {
    let c = async || {
        *x;
        //~^ ERROR cannot move out of `*x` which is behind a shared reference
    };
}

fn main() {}

The parent coroutine-closure captures x: &Ty by-ref, resulting in an upvar of &&Ty. The child coroutine captures x by-value, resulting in an upvar of &Ty. When constructing the by-move body for the coroutine-closure, we weren't applying an additional deref projection to convert the parent capture into the child capture, resulting in an type error in assignment, which is a validation ICE.

As I said above, this only occurs (AFAICT) in code that eventually results in an error, because it is only triggered by HIR that attempts to move a non-copy value out of a ref. This doesn't occur if Ty is Copy, since we'd instead capture x by-ref in the child coroutine.

Fixes #129074

[rustbot]

r? @saethlin

rustbot has assigned @saethlin.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[compiler-errors]

r? lcnr

lol idk who else to request review from sorry

[lcnr]

@bors r+ rollup

This doesn't affect the child_capture.is_by_ref() && !parent_capture.is_by_ref() case, but only the !child_capture.is_by_ref() && parent_capture.is_by_ref() which as stated, only happens if the child moves something which the parent context borrowed, so it should always error.

While I don't fully understand the surrounding context, the change itself doesn't seem to make anything worse and I trust both @compiler-errors and MIR validation to catch any issues.

[lcnr]

@bors r+ rollup

[bors]

📌 Commit 1e1d839 has been approved by lcnr

It is now in the queue for this repository.

[workingjubilee]

forget about it, homu. the loop's over.

@bors r-