You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If I change this function to trigger an error when using StorageDead on a local that is already dead, that shows that we do generate MIR with redundant StorageDead. I am not sure if we should consider this a bug, but given that we consider redundant StorageLive a bug (due to some rather vague language on the LLVM side, that seems safer), I wonder if we should do the same for StorageDead?
Here's an execution trace (from CTFE) of such a piece of MIR:
├─┐rustc_const_eval::interpret::eval_context::frame core::num::<impl i8>::checked_div
│ ├─0ms INFO rustc_const_eval::interpret::step // executing bb0
│ ├─0ms INFO rustc_const_eval::interpret::step StorageLive(_3)
│ ├─0ms INFO rustc_const_eval::interpret::step StorageLive(_4)
│ ├─0ms INFO rustc_const_eval::interpret::step StorageLive(_5)
│ ├─0ms INFO rustc_const_eval::interpret::step StorageLive(_6)
│ ├─0ms INFO rustc_const_eval::interpret::step _6 = _2
│ ├─0ms INFO rustc_const_eval::interpret::step _5 = Eq(move _6, const 0_i8)
│ ├─0ms INFO rustc_const_eval::interpret::step StorageDead(_6)
│ ├─0ms INFO rustc_const_eval::interpret::step switchInt(move _5) -> [false: bb2, otherwise: bb1]
│ ├─0ms INFO rustc_const_eval::interpret::step // executing bb2
│ ├─0ms INFO rustc_const_eval::interpret::step StorageLive(_7)
│ ├─0ms INFO rustc_const_eval::interpret::step StorageLive(_8)
│ ├─0ms INFO rustc_const_eval::interpret::step StorageLive(_9)
│ ├─0ms INFO rustc_const_eval::interpret::step _9 = _1
│ ├─0ms INFO rustc_const_eval::interpret::step _8 = Eq(move _9, const core::num::<impl i8>::MIN)
│ ├─0ms INFO rustc_const_eval::interpret::step StorageDead(_9)
│ ├─0ms INFO rustc_const_eval::interpret::step switchInt(move _8) -> [false: bb4, otherwise: bb5]
│ ├─0ms INFO rustc_const_eval::interpret::step // executing bb4
│ ├─0ms INFO rustc_const_eval::interpret::step _7 = const false
│ ├─0ms INFO rustc_const_eval::interpret::step goto -> bb6
│ ├─0ms INFO rustc_const_eval::interpret::step // executing bb6
│ ├─0ms INFO rustc_const_eval::interpret::step StorageDead(_10)
As you can see, _10 was never marked as live, and yet it is marked as dead here.
Unfortunately I do not know a good way to get the CTFE MIR of a standard library function. I tried copying its code to generate the MIR separately, but that looks pretty different from the above trace.
If I change this function to trigger an error when using StorageDead on a local that is already dead, that shows that we do generate MIR with redundant StorageDead. I am not sure if we should consider this a bug, but given that we consider redundant StorageLive a bug (due to some rather vague language on the LLVM side, that seems safer), I wonder if we should do the same for StorageDead?
Here's an execution trace (from CTFE) of such a piece of MIR:
As you can see,
_10
was never marked as live, and yet it is marked as dead here.Unfortunately I do not know a good way to get the CTFE MIR of a standard library function. I tried copying its code to generate the MIR separately, but that looks pretty different from the above trace.
Cc @tmandry @JakobDegen
The text was updated successfully, but these errors were encountered: