Mark more locals as moved to avoid building drops for them.

[cjgillot]

View all comments

MIR building skips generating drops for moved-from locals in the topmost scope. This was only used for call terminators, but can be generalized to many other moves. This PR generalizes this to aggregate construction and many other assignments.

This avoids generating drops that would then be removed by drop elaboration.

This PR changes borrowck behaviour: some programs that were rejected are now accepted, see the last commit. That particular case was wrongly rejected.

Fixes#156713

Based on #158279 to remove a lint false-positive

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[rustbot]

r? @JohnTitor

rustbot has assigned @JohnTitor.
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

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 73 candidates
• Random selection from 21 candidates

[theemathas]

Does this have user-visible behavior changes? e.g., see #156713

[cjgillot]

Yes. With this change, both cases in #156713 pass. We also have a few user-visible consequences with the drop order lint.

[JohnTitor]

@rustbot reroll

[cjgillot]

@bors try @rust-timer queue

[jackh726]

I'm not personally very familiar with when we are allowed to avoid building drops (specifically, which are these truly count as moves from an opsem perspective).

cc both @rust-lang/opsem and @rust-lang/types

I would be far more comfortable if there was a small and specific test demonstrating the difference from marking each individual site that we record as moved.

[RalfJung]

I'm afraid MIR building is mostly outside my wheelhouse.
But Cc @Amanieu since you said "move".

[RalfJung]

Is there somewhere a high-level description of the algorithm implemented here and how it defines "move"?
It seems like this first builds MIR and then looks at the just-built MIR to determine what the "moves" are?

[cjgillot]

Is there somewhere a high-level description of the algorithm implemented here and how it defines "move"?

At high level, the doc-comment on record_operand_moved is quite good.
There is also the definition by @nikomatsakis here: rust-lang/compiler-team#558

It seems like this first builds MIR and then looks at the just-built MIR to determine what the "moves" are?

This is on the "built" MIR phase. In short, a "move" is an occurrence of Operand::Move, which deinitializes the moved-from place. In that MIR dialect, drop actually means drop-if-initialized, so drops of moved-from locals is a no-op, and can be elided. (See the section on "drops" here: https://doc.rust-lang.org/beta/nightly-rustc/rustc_middle/mir/enum.MirPhase.html)

[cjgillot]

I would be far more comfortable if there was a small and specific test demonstrating the difference from marking each individual site that we record as moved.

Latest push adds a mir-opt test file with the different cases, and shows what changes. Not all calls to record_operand_moved have an effect, as it is very conservative, in particular when locals are declared in different scopes.

[RalfJung]

a "move" is an occurrence of Operand::Move, which deinitializes the moved-from place

"de-initialize" here refers to the initialization state tracked for drop flags, right?
We don't currently have a MIR semantics where this actually changes the contents of memory to be uninitialized.

[cjgillot]

"de-initialize" here refers to the initialization state tracked for drop flags, right?

Yes

[RalfJung]

"de-initialize" here refers to the initialization state tracked for drop flags, right?

Yes

This should probably be mentioned in the Operand::Move doc comment.

[rustbot]

This PR changes MIR

cc @oli-obk, @RalfJung, @JakobDegen, @vakaras

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[rust-bors]

☔ The latest upstream changes made this pull request unmergeable. Please resolve the merge conflicts by rebasing.