MIR move elimination by Amanieu · Pull Request #3943 · rust-lang/rfcs

Amanieu · 2026-04-03T13:34:19Z

This RFC proposes changes to Rust's operational semantics and MIR representation to enable elimination of unnecessary copies of local variables. Specifically, it makes accessing memory after a move undefined behavior, and redefines the allocation lifetime of local variables to be tied to their initialized state rather than their lexical scope. Finally, it introduces a new MIR optimization pass which exploits these guarantees to eliminate copies between locals when it is safe to do so.

Important

Since RFCs involve many conversations at once that can be difficult to follow, please use review comment threads on the text changes instead of direct comments on the RFC.

If you don't have a particular section of the RFC to comment on, you can click on the "Comment on this file" button on the top-right corner of the diff, to the right of the "Viewed" checkbox. This will create a separate thread even if others have commented on the file too.

Rendered

NobodyXu · 2026-04-03T14:26:57Z

For Copy-iable types, can rust mir just drop them after the last usage, given that it cannot have a Drop implementation?

It seems to be extremely strange to say I need a move keyword on a Copy-iable type just so the compiler can optimize it

Amanieu · 2026-04-03T15:45:55Z

For Copy-iable types, can rust mir just drop them after the last usage, given that it cannot have a Drop implementation?

It seems to be extremely strange to say I need a move keyword on a Copy-iable type just so the compiler can optimize it

We can drop Copy types after the last usage as long as they've not been borrowed. If they have then the compiler would need to additionally prove through alias analysis that the borrow has ended. This is necessary because stack/tree borrows allows a pointer/reference to continue accessing a local after it has been copied (but not moved).

The purpose of a move keyword would be to forcibly end the borrows of a local early, which allows the local to be freed at that point. This would also be enforced by the borrow checker for references.

NobodyXu · 2026-04-03T16:25:16Z

The purpose of a move keyword would be to forcibly end the borrows of a local early, which allows the local to be freed at that point. This would also be enforced by the borrow checker for references.

Wouldn't it make more sense to have something similar to drop to force drop it, and that can also work on non-Copy-iable type as well, for generic functions?

Amanieu · 2026-04-03T19:10:18Z

Calling drop(x) on a Copy type doesn't do anything since x is copied. The new keyword would allow you to write drop(move x) which forces x to be moved. Here's an example where this matters:

let x = 1;
let y = &x;
drop(move x);
let z = *y; // Fails because x was moved. Removing `move` fixes this.

Anyways, move isn't even being proposed in this RFC, it's a possible future extension.

PoignardAzur · 2026-04-04T09:26:39Z

Since RFCs involve many conversations at once that can be difficult to follow, please use review comment threads on the text changes instead of direct comments on the RFC.

Jules-Bertholet · 2026-04-07T15:03:58Z

+
+The proposed behavior of freeing a local variable's allocation on move only applies when the entire variable is moved. This is not the case when only a part of the variable is moved (e.g. only one field of a struct) because a re-initialized field must retain the address it had before, reintroducing the same NB issue.
+
+Even in the case where all of the fields of a local variable have been moved out one-by-one, the local will not be freed.


Even in the case where all of the fields of a local variable have been moved out one-by-one, the local will not be freed.

Why not?

Jules-Bertholet · 2026-04-07T15:19:03Z

+
+Even in the case where all of the fields of a local variable have been moved out one-by-one, the local will not be freed.
+
+With that said, we would like to keep the door open for potentially switching to operational semantics with NB in the future. So although the proposed opsem does not consider accessing a moved field as UB, we would like users to avoid relying on this behavior since it may change in the future.


Why can't we say that accessing the moved field is UB? Because we don't have NB, the compiler can't exploit that UB by stashing another allocation with an observable address in the empty space. But that doesn't mean it can't still be UB detected by Miri, if we want users to avoid relying on it. And the compiler could even make use of the UB, to stash an allocation whose address it can prove is never observed.

There's no reason we can't do it, it's just that I am not doing so in this RFC and instead leaving to future work (I will update the future possibilities section with this). There are 2 main reasons for this:

Adding support for partial moves makes the opsem (and by extension Miri) much more complex since we now needs to track which bytes of a local have been moved out and become "inactive" (UB to access). What happens to the padding of a struct if one field is moved out? What happens to the discriminant of an enum like Option<T> if the Some value has been moved out and the layout is optimized (the discriminant occupied the same bytes as the value)? These are all questions that would have to be answered.

The proposed MIR optimization pass can't easily take advantage of this, and even if it could (while respecting address observation rules) then I expect the benefit over the existing proposed pass would be minimal. It's just not worth the extra complexity of tracking lifetimes separately for every field of a local.

oskgo · 2026-04-09T15:03:39Z

+
+## Drawbacks
+
+### `Copy` is no longer "free"


This makes it sound as though types with Copy would be less efficient than with the status quo, but as far as I understand this is not the case. Copy types would at worst be as efficient as with the status quo.

This sounds more like a limitation (AKA an opportunity for future work) than a drawback.

It's also not clear to me why the mere act of implementing Copy for a type would inhibit the optimization in practice. Surely code that was originally written for a non-Copy type would have an access pattern where every copy could be optimized into a move?

This makes it sound as though types with Copy would be less efficient than with the status quo, but as far as I understand this is not the case. Copy types would at worst be as efficient as with the status quo.

That is correct.

This sounds more like a limitation (AKA an opportunity for future work) than a drawback.

Sure, I can move this to the future work section.

It's also not clear to me why the mere act of implementing Copy for a type would inhibit the optimization in practice. Surely code that was originally written for a non-Copy type would have a copy pattern where every copy could be optimized into a move?

It inhibits the optimization if the value has been borrowed. A move invalidates borrows whereas a copy doesn't. I've update the text with an example.

RalfJung

Finally had the time for a first read over this.

I haven't yet had the chance to look at your MiniRust patch, that may answer some of the questions that came up here. But of course ideally the RFC itself is already crystal clear about the intended MR semantics. :)

View changes since this review

RalfJung · 2026-05-10T17:32:40Z

+
+#### Initialization
+
+`StorageLive` no longer allocates the underlying memory for a local. Instead, any MIR statement or terminator which writes to a place that has no `Deref` projections[^2] will implicitly allocate the storage for that local[^3] before writing to it. This has no effect if the storage for that local is already allocated[^4].


To make it sound to generate LLVM lifetime markers from StorageLive, we will need to do something in the opsem for StorageLive.

Reading on, you clarify this later, but the order in which you explain this is confusing.

I've kept the original ordering since for most people it's better to give an overview of the intended semantics first before diving into a more formal specification for StorageDead/StorageLive. However I have added a link to that in the section intro.

RalfJung · 2026-05-10T17:49:28Z

+
+`move` operands only have the effect of de-allocating the storage of a local when used with a bare, unprojected local. If the local has projections then `move` behaves identically to `copy`.
+
+#### New semantics of `StorageLive` and `StorageDead`


This RFC also inevitable deeply changes the semantics of assignments. There should be a section on that.

And this section is where I have the biggest disagreement with the RFC: the RFC proposes to make (de)allocation of locals an implicit side-effect of (some) place/value expressions. I think that's a problem for multiple reasons

It breaks the property that expression evaluation can be arbitrarily reordered with each other, making it harder to reason about MIR.

For places it's not even clear how evaluation should work. I can make guesses but the RFC is not very clear about it. (EDIT: This one is answered by the MiniRust patch.)

I would propose that instead the (de)allocation happens as part of the assignment operator. The way I think about it is that the operator performs the following steps:

evaluate the value expression (RHS)

deallocate a set of locals

allocate a set of locals

evaluate the place expression (LHS)

store the value into the place

In MiniRust, it's probably easiest to just annotate those two sets of locals as part of the syntax of assignment itself. In MIR, we might want to make that implicit. That would then be able to capture the syntactic ruls you have proposed elsewhere:

for the locals to deallocate: if the RHS is Use(Move(local)), then local is deallocated, otherwise nothing gets deallocated. (Or is it really all Move(local) operands on the RHS? I can see it being useful for aggregate initialization but I doubt this makes much sense for binops.)

for the locals to allocate: if the LHS is local.non-deref-projs, then local gets allocated, otherwise nothing gets allocated

As per our discussion on Zulip, I've kept the existing semantics of doing allocation/de-allocation as part of destination place/input operand evaluation. I've added bulk allocation/deallocation as an alternative option, but in the end both options are workable for MIR optimizations, the only difference is in how they are handled in Miri/MiniRust.

It is outside the scope of this RFC and just confuses things.

…-to-move, r=tmiasko MIR move elimination [2/6]: TailCopyToMove Depends on rust-lang#163335 This PR implements a pre-pass for the `MoveElimination` pass from rust-lang/rfcs#3943. `TailCopyToMove` turns `Copy` into `Move` just before a `Return` terminator. This is valid even for places that have been borrowed because the `Return` will invalidate borrows anyway. This is necessary to allow the source of the copy to be unified with the return place. r? tmiasko

RalfJung · 2026-09-30T11:49:06Z

+
+[^dest-alias]: The normal rules would allow this overlap, which assignments use. But this would break in-place argument passing in codegen.
+
+These rules continue to allow codegen to pass `move` arguments in-place: the deallocation of bare-local `move` operands allows the corresponding argument in the callee to re-use the same address as the deallocated local. Also note that the exceptions are specific to `Call` terminators. They do not apply to `TailCall`, `InlineAsm`, `Yield`, which continue to use the standard operand evaluation rules.


They do not apply to TailCall, InlineAsm, Yield, which continue to use the standard operand evaluation rules.

Those rules are for statements. I have no idea what it means to apply them to terminators.

Call and TailCall having different rules sound quite confusing and is IMO undesirable.

View changes since the review

There's nothing specific about these rules that make them only apply to statements?

Call and TailCall already have different rules today because TailCall doesn't allow in-place passing. In fact of all terminators, Call is the special case because it is the only MIR statement/termiantor that treats move with special semantics to allow in-place calls. I've previously argued that we should use something other than Operand for call terminators for this reason.

I've rust-lang/rust#71117 (comment) that we should use something other than Operand for call terminators for this reason.

That's also the conclusion we reached in the opsem call, I think.

RalfJung · 2026-09-30T11:50:05Z

+This RFC makes calls mostly follow the same rules as assignments: operands are evaluated left to right, with bare-local moves deallocating the local as part of evaluating that operand. The destination place is evaluated last and, if direct, will allocate its base local if needed.
+
+There are 2 exceptions to this:
+- `move` operands with projections keep their old semantics: the moved place is donated to the callee. This place is required to not overlap with the destination place.


So move _1 and move _1.field have completely different semantics? That doesn't sound like a good idea, it sounds like a headache and a footgun.

View changes since the review

That's already the case for normal (non-call) operand evaluation: move _1 will de-allocate the local but move _1.field is treated the same as a copy.

move *_1 is definitively treated as move, not copy (otherwise impl FnOnce() for Box<dyn FnOnce()> couldn't work). And cg_clif also treats move _1.field as move and doesn't copy it on the caller side, allowing the callee to reuse it in-place: https://github.com/rust-lang/rust/blob/7d2cd0fbc092625ea371da704f15f80216d2220e/compiler/rustc_codegen_cranelift/src/abi/mod.rs#L416-L424

That's already the case for normal (non-call) operand evaluation

Before this RFC it's not the case, it's all nice and homogeneous.

If this RFC makes things messy also for non-call operands that's not really helping.^^

The main change in this RFC is that moves of a whole local now deallocate the local. Otherwise it behaves the same as before.

Old semantics New semantics

Normal operand copy _1 Copies the value, source unchanged Copies the value, source unchanged

Normal operand move _1 Same as copy Deallocates _1 during evaluation

Normal operand move _1.field Same as copy Same as copy

Call operand copy _1 Copies the value, source unchanged Copies the value, source unchanged

Call operand move _1 Protects _1 for duration of call Deallocates _1 during evaluation

Call operand move _1.field Protects _1.field for duration of call Protects _1.field for duration of call

(.field in this table generalizes to any projection, including deref)

Note that both deallocation and protection permit the codegen optimization of in-place passing. Deallocation allows it because it allows the local in the callee's stack frame to re-use the newly freed address. Protection allows it because the protected area is temporarily donated for the callee to allocate its locals from. No changes to codegen were required by the change from protection to deallocation.

Deallocation also cleanly detects overlaps with other move operands and the destination as UB:

UB if the local was already protected or deallocated by an earlier operand evaluation.

Later attempts to protect or deallocate the place will be UB since it has been deallocated.

And finally, it deallocates moved locals before the callee executes, which means the stack frame doesn't need to keep track of a set of locals to deallocate on return.

In the call we (IIUC) agreed that move would only be allowed on bare locals for runtime MIR, so then we can say that move always deallocates. That resolves this concern.

RalfJung · 2026-09-30T11:57:19Z

+- We specifically forbid the destination place from having the same base local as a bare-local moved argument.[^dest-alias]
+
+[^dest-alias]: The normal rules would allow this overlap, which assignments use. But this would break in-place argument passing in codegen.
+


What does "forbid" mean? Is it UB, or invalid MIR?

This all feels like it's papering over a deeper problem by adding increasingly baroque exceptions and special cases. :/

View changes since the review

Invalid MIR. It was already UB in the old semantics because of the overlap between source and destination, this just makes the guarantee stronger.

Previously UB naturally fell out of the semantics without special cases. Now there's more special cases that everyone dealing with MIR semantics needs to figure out and remember. That's an increase in entropy.

Why is it invalid MIR now?

Because without that extra rule, it would be legal to have _1 = foo(move _1) without Miri detecting any UB. Previously this would have been caught because protecting both the destination and the moved operand would result in a conflict, which is UB. Under the new semantics, _1 is freed by operand evaluation, and then re-initialized with a new allocation by destination evaluation. This works fine in the abstract machine, but breaks in-place passing in codegen.

The solution that I chose is to make the specific case where the same local is freed and the re-initialized in the destination invalid MIR specifically for calls. But there are also alternative solutions that achieve the same effect:

Make it UB instead of invalid MIR.

Allow it and have codegen detect this specific situation, in which case it must treat the move _1 as a copy and not pass it in-place.

Rollup merge of #163336 - Amanieu:move-elimination/tail-copy-to-move, r=tmiasko MIR move elimination [2/6]: TailCopyToMove Depends on #163335 This PR implements a pre-pass for the `MoveElimination` pass from rust-lang/rfcs#3943. `TailCopyToMove` turns `Copy` into `Move` just before a `Return` terminator. This is valid even for places that have been borrowed because the `Return` will invalidate borrows anyway. This is necessary to allow the source of the copy to be unified with the return place. r? tmiasko

…iveness, r=tmiasko MIR move elimination [3/6]: PreciseLiveness Depends on rust-lang#163335 This PR implements the lifetime analysis used by the `MoveElimination` pass from rust-lang/rfcs#3943. `PreciseLiveness` calculates, at a sub-statement granularity, the points in a function where a local requires storage to be allocated. This is more fine-grained than `MaybeStorageLive`, and takes borrows into account. r? tmiasko

Rollup merge of #163337 - Amanieu:move-elimination/precise-liveness, r=tmiasko MIR move elimination [3/6]: PreciseLiveness Depends on #163335 This PR implements the lifetime analysis used by the `MoveElimination` pass from rust-lang/rfcs#3943. `PreciseLiveness` calculates, at a sub-statement granularity, the points in a function where a local requires storage to be allocated. This is more fine-grained than `MaybeStorageLive`, and takes borrows into account. r? tmiasko

…ination, r=tmiasko MIR move elimination [4/6]: MoveElimination Depends on rust-lang#163336 and rust-lang#163337 This PR implements the `MoveElimination` pass from rust-lang/rfcs#3943. This pass uses the analysis results from `PreciseLiveness` to unify locals that are related by an assignment. This also includes an alias-fixup pass which is needed because some rvalues don't allow sources to overlap with the destination place. The pass is only enabled under `-Zmir-move-elimination`. This flag also disables `DestinationPropagation`, which is superseded by the new pass. r? tmiasko

Rollup merge of #163338 - Amanieu:move-elimination/move-elimination, r=tmiasko MIR move elimination [4/6]: MoveElimination Depends on #163336 and #163337 This PR implements the `MoveElimination` pass from rust-lang/rfcs#3943. This pass uses the analysis results from `PreciseLiveness` to unify locals that are related by an assignment. This also includes an alias-fixup pass which is needed because some rvalues don't allow sources to overlap with the destination place. The pass is only enabled under `-Zmir-move-elimination`. This flag also disables `DestinationPropagation`, which is superseded by the new pass. r? tmiasko

…econstruction, r=tmiasko MIR move elimination [5/6]: Storage reconstruction Depends on rust-lang#163338 This PR extends the `MoveElimination` pass from rust-lang/rfcs#3943 to reconstruct `StorageLive`/`StorageDead` statements for all locals by using the liveness information collected by `PreciseLiveness`. r? tmiasko

…alization, r=dianqk MIR move elimination [1.5/6]: Ensure ZSTs are always initialized Split off from rust-lang#163335 The new MIR semantics from rust-lang/rfcs#3943 require that a local be initialized before it is used, since it only gains an allocation at that point. This means that ZSTs must be initialized before being read, even though the initialization is a no-op in codegen. This PR addresses this in 2 ways: - Adds missing ZST initializations in MIR shims and MIR intrinsic lowering. - Restricts the `RemoveZsts` pass to only remove ZST assignments when the destination is indirect, since such places are required to already be allocated anyways. This is fine in practice since dead ZST assignments are later removed by DSE. The last one also exposed a limitation in `SimplifyMatch`'s handling of constant equality when checking if two match arms are equivalent: it was only checking for scalar constants and was not handling `()` unit constants, which resulted in a test regression. The pass has been fixed to handle any kind of `ConstValue`. r? tmiasko

Rollup merge of #163339 - Amanieu:move-elimination/storage-reconstruction, r=tmiasko MIR move elimination [5/6]: Storage reconstruction Depends on #163338 This PR extends the `MoveElimination` pass from rust-lang/rfcs#3943 to reconstruct `StorageLive`/`StorageDead` statements for all locals by using the liveness information collected by `PreciseLiveness`. r? tmiasko

Rollup merge of #163359 - Amanieu:move-elimination/zst-initialization, r=dianqk MIR move elimination [1.5/6]: Ensure ZSTs are always initialized Split off from #163335 The new MIR semantics from rust-lang/rfcs#3943 require that a local be initialized before it is used, since it only gains an allocation at that point. This means that ZSTs must be initialized before being read, even though the initialization is a no-op in codegen. This PR addresses this in 2 ways: - Adds missing ZST initializations in MIR shims and MIR intrinsic lowering. - Restricts the `RemoveZsts` pass to only remove ZST assignments when the destination is indirect, since such places are required to already be allocated anyways. This is fine in practice since dead ZST assignments are later removed by DSE. The last one also exposed a limitation in `SimplifyMatch`'s handling of constant equality when checking if two match arms are equivalent: it was only checking for scalar constants and was not handling `()` unit constants, which resulted in a test regression. The pass has been fixed to handle any kind of `ConstValue`. r? tmiasko

RalfJung · 2026-10-21T16:20:54Z

+[^5]: [rust-lang/rust#71117](https://github.com/rust-lang/rust/issues/71117)
+[^6]: The exact behavior is still an open question today (which this RFC specifies), but this describes what codegen currently does.
+
+This RFC makes calls mostly follow the same rules as assignments: operands are evaluated left to right, with bare-local moves deallocating the local as part of evaluating that operand. The destination place is evaluated last and, if direct, will allocate its base local if needed.


The destination place is evaluated last

But still before the call, right?

View changes since the review

RalfJung · 2026-10-21T16:22:50Z

+| Function entry (other locals with storage markers) | N/A | State starts as **dead**[^markers] |
+| `StorageLive` | None | State becomes **live**[^live] |
+| `StorageDead` | None | State becomes **dead** |
+| `StorageAlloc` | UB if **dead** | State becomes **allocated** |


StorageAlloc preserves the old content if it exists, right? Would be good to also show that here, not just in the text above.

View changes since the review

RalfJung · 2026-11-02T15:19:06Z

+
+[^dest-alias]: The normal rules would allow this overlap, which assignments use. But this would break in-place argument passing in codegen.
+
+These rules continue to allow codegen to pass `move` arguments in-place: the deallocation of bare-local `move` operands allows the corresponding argument in the callee to re-use the same address as the deallocated local. Also note that the exceptions are specific to `Call` terminators. They do not apply to `TailCall`, `InlineAsm`, `Yield`, which continue to use the standard operand evaluation rules.


I've rust-lang/rust#71117 (comment) that we should use something other than Operand for call terminators for this reason.

That's also the conclusion we reached in the opsem call, I think.

RalfJung · 2026-11-02T15:20:19Z

+This RFC makes calls mostly follow the same rules as assignments: operands are evaluated left to right, with bare-local moves deallocating the local as part of evaluating that operand. The destination place is evaluated last and, if direct, will allocate its base local if needed.
+
+There are 2 exceptions to this:
+- `move` operands with projections keep their old semantics: the moved place is donated to the callee. This place is required to not overlap with the destination place.


In the call we (IIUC) agreed that move would only be allowed on bare locals for runtime MIR, so then we can say that move always deallocates. That resolves this concern.

Add MIR move elimination RFC

08e705c

Amanieu mentioned this pull request Apr 3, 2026

MIR move elimination rust-lang/goals#396

Open

Address feedback

064fd25

Noratrieb added T-compiler Relevant to the compiler team, which will review and decide on the RFC. T-opsem Relevant to the operational semantics team, which will review and decide on the RFC. labels Apr 5, 2026

Amanieu added the T-lang Relevant to the language team, which will review and decide on the RFC. label Apr 5, 2026

scottmcm reviewed Apr 6, 2026

View reviewed changes

Comment thread text/0000-mir-move-elimination.md Resolved

Remove incorrect paragraph about initializing locals with undef

d4e779c

Jules-Bertholet reviewed Apr 7, 2026

View reviewed changes

Amanieu removed the T-lang Relevant to the language team, which will review and decide on the RFC. label Apr 7, 2026

oskgo reviewed Apr 9, 2026

View reviewed changes

Move the discussion about the move keyword to future possibilities

b08ba08

Amanieu mentioned this pull request Apr 29, 2026

MIR Call terminator: evaluate destination place before arguments rust-lang/rust#155932

Merged

Clarify that the behavior of partial moves remains unspecified

f330dc8

Amanieu mentioned this pull request May 7, 2026

Landing the MIR move elimination optimization rust-lang/all-hands-2026#63

Open

RalfJung reviewed May 10, 2026

View reviewed changes

Amanieu mentioned this pull request May 13, 2026

Semantics of MIR assignments, around aliasing, ordering, and primitives. rust-lang/rust#68364

Open

Remove changes to MIR call terminators

e297f9c

It is outside the scope of this RFC and just confuses things.

This comment was marked as outdated.

Sign in to view

RalfJung mentioned this pull request May 22, 2026

Can I create and use a *mut to an uninitialized local? rust-lang/rust#90718

Open

Amanieu added 4 commits May 24, 2026 22:44

Address feedback from Ralf

5b026c6

Rewrite implementation section based on prototype implementation

e4a6bb3

Clarify impact on dead store elimination

8f70e15

Minor cleanups

d3ef678

This was referenced Sep 25, 2026

MIR move elimination [6/6]: Miri support rust-lang/rust#163340

Draft

MIR move elimination [1.5/6]: Ensure ZSTs are always initialized rust-lang/rust#163359

Merged

RalfJung reviewed Sep 30, 2026

View reviewed changes

Amanieu mentioned this pull request Oct 1, 2026

Add merge yields pass rust-lang/rust#162429

Open

madsmtm reviewed Oct 10, 2026

View reviewed changes

Comment thread text/0000-mir-move-elimination.md Resolved

RalfJung reviewed Nov 2, 2026

View reviewed changes


		The proposed behavior of freeing a local variable's allocation on move only applies when the entire variable is moved. This is not the case when only a part of the variable is moved (e.g. only one field of a struct) because a re-initialized field must retain the address it had before, reintroducing the same NB issue.

		Even in the case where all of the fields of a local variable have been moved out one-by-one, the local will not be freed.


		Even in the case where all of the fields of a local variable have been moved out one-by-one, the local will not be freed.

		With that said, we would like to keep the door open for potentially switching to operational semantics with NB in the future. So although the proposed opsem does not consider accessing a moved field as UB, we would like users to avoid relying on this behavior since it may change in the future.


		#### Initialization

		`StorageLive` no longer allocates the underlying memory for a local. Instead, any MIR statement or terminator which writes to a place that has no `Deref` projections[^2] will implicitly allocate the storage for that local[^3] before writing to it. This has no effect if the storage for that local is already allocated[^4].


		`move` operands only have the effect of de-allocating the storage of a local when used with a bare, unprojected local. If the local has projections then `move` behaves identically to `copy`.

		#### New semantics of `StorageLive` and `StorageDead`


		[^dest-alias]: The normal rules would allow this overlap, which assignments use. But this would break in-place argument passing in codegen.

		These rules continue to allow codegen to pass `move` arguments in-place: the deallocation of bare-local `move` operands allows the corresponding argument in the callee to re-use the same address as the deallocated local. Also note that the exceptions are specific to `Call` terminators. They do not apply to `TailCall`, `InlineAsm`, `Yield`, which continue to use the standard operand evaluation rules.

	Old semantics	New semantics
Normal operand `copy _1`	Copies the value, source unchanged	Copies the value, source unchanged
Normal operand `move _1`	Same as copy	Deallocates `_1` during evaluation
Normal operand `move _1.field`	Same as copy	Same as copy
Call operand `copy _1`	Copies the value, source unchanged	Copies the value, source unchanged
Call operand `move _1`	Protects `_1` for duration of call	Deallocates `_1` during evaluation
Call operand `move _1.field`	Protects `_1.field` for duration of call	Protects `_1.field` for duration of call

		- We specifically forbid the destination place from having the same base local as a bare-local moved argument.[^dest-alias]

		[^dest-alias]: The normal rules would allow this overlap, which assignments use. But this would break in-place argument passing in codegen.

Conversation

Amanieu commented Apr 3, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

NobodyXu commented Apr 3, 2026

Uh oh!

Amanieu commented Apr 3, 2026

Uh oh!

NobodyXu commented Apr 3, 2026

Uh oh!

Amanieu commented Apr 3, 2026

Uh oh!

PoignardAzur commented Apr 4, 2026

Uh oh!

Uh oh!

Jules-Bertholet Apr 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Amanieu Apr 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

oskgo Apr 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

RalfJung May 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

This comment was marked as outdated.

RalfJung Sep 30, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung Sep 30, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung Sep 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Amanieu commented Apr 3, 2026 •

edited by rustbot

Loading

Jules-Bertholet Apr 7, 2026 •

edited

Loading

Amanieu Apr 7, 2026 •

edited

Loading

oskgo Apr 9, 2026 •

edited

Loading

RalfJung left a comment •

edited by rustbot

Loading

RalfJung May 10, 2026 •

edited

Loading

RalfJung Sep 30, 2026 •

edited by rustbot

Loading

RalfJung Sep 30, 2026 •

edited by rustbot

Loading

RalfJung Sep 30, 2026 •

edited

Loading

RalfJung Sep 30, 2026 •

edited by rustbot

Loading

RalfJung Oct 21, 2026 •

edited by rustbot

Loading

RalfJung Oct 21, 2026 •

edited by rustbot

Loading