about summary refs log tree commit diff
path: root/compiler/rustc_interface/src
diff options
context:
space:
mode:
authorMatthias Krüger <matthias.krueger@famsik.de>2023-02-08 18:32:41 +0100
committerGitHub <noreply@github.com>2023-02-08 18:32:41 +0100
commit05748c66a0cdf76500672827d98732e7bdbb0ac4 (patch)
tree507c50cd9be02b3e3d951d7ed09fdc978ebd6b6e /compiler/rustc_interface/src
parent562581c2db7ae9294e16f84deeef1dcdaae18152 (diff)
parent68c1e2fd484b430726881f822311b4e9aa9c044d (diff)
downloadrust-05748c66a0cdf76500672827d98732e7bdbb0ac4.tar.gz
rust-05748c66a0cdf76500672827d98732e7bdbb0ac4.zip
Rollup merge of #107271 - Zeegomo:drop-rmw, r=oli-obk
Treat Drop as a rmw operation

Previously, a Drop terminator was considered a move in MIR. This commit changes the behavior to only treat Drop as a mutable access to the dropped place.

In order for this change to be correct, we need to guarantee that

1.  A dropped value won't be used again
   2.  Places that appear in a drop won't be used again before a
     subsequent initialization.

We can ensure this to be correct at MIR construction because Drop will only be emitted when a variable goes out of scope, thus having:
*   (1) as there is no way of reaching the old value. drop-elaboration
     will also remove any uninitialized drop.
 * (2) as the place can't be named following the end of the scope.

However, the initialization status, previously tracked by moves, should also be tied to the execution of a Drop, hence the additional logic in the dataflow analyses.

From discussion in [this thread](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/.60DROP.60.20to.20.60DROP_IF.60.20compiler-team.23558), originating from https://github.com/rust-lang/compiler-team/issues/558.
See also https://github.com/rust-lang/rust/pull/104488#discussion_r1085556010
Diffstat (limited to 'compiler/rustc_interface/src')
0 files changed, 0 insertions, 0 deletions