Skip to content

Conversation

@sladyn98
Copy link
Contributor

@sladyn98 sladyn98 commented Nov 29, 2025

This PR fixes a soundness bug where local variables are deallocated out of order during panic unwinding, allowing destructors to access freed memory. This violates Rust's safety guarantees and has caused real-world unsoundness in crates like generatively.

This PR removes the is_generator check and unconditionally emits StorageDead statements during unwinding for ALL functions, bringing non-generator behavior in line with generators. It ensures that during unwinding, when a local variable goes out of scope, its storage is properly marked as dead via StorageDead, allowing the borrow checker to enforce the
invariant that values must outlive their references even in panic paths.

Fixes #147875

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Nov 29, 2025
@rustbot
Copy link
Collaborator

rustbot commented Nov 29, 2025

r? @wesleywiser

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

@sladyn98
Copy link
Contributor Author

r? @dianne

@rustbot rustbot assigned dianne and unassigned wesleywiser Nov 29, 2025
@rust-log-analyzer

This comment has been minimized.

Copy link
Contributor

@dianne dianne left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like there's a bug causing an assertion failure when building the standard library. I've given it a look and offered a guess at what's causing it below. There's still work to do here beyond fixing that, though.

First, could you add a ui test to demonstrate that this fixes #147875? It looks like it might not yet, since the code for scheduling unwind drops on calls panicking looks unchanged.

Second, after verifying that this results in the correct borrow-checking behavior, we need to make sure that this change doesn't negatively affect codegen. Per the old comment on needs_cleanup, at least at the time it was written, LLVM didn't handle the unnecessary cleanup blocks and StorageDeads particularly well. If you can demonstrate with codegen tests that that's not an issue anymore, and perf isn't too bad, that might be all that's needed. But my expectation is that we'll have to get rid of or ignore the StorageDeads later in compilation (sometime after they serve their purpose in borrowck). Unless there's a reason to keep the StorageDeads around longer, my gut feeling is that this cleanup would be best as a post-borrowck MIR pass (maybe as part of CleanupPostBorrowck?), since then optimization passes can be done on cleaner MIR and we can test it works with MIR tests rather than codegen tests. Could you also add a test for this not affecting later stages of compilation? If you accomplish that by removing the unwind-path StorageDeads as part of a MIR pass, that'd be a mir-opt test.

Before you push again, you'll probably want to run the codegen and mir-opt tests to make sure the former is clean and to bless the latter. Regardless of what approach we take here, if we're changing how the MIR is built, there should be differences in the MIR building test output (part of the mir-opt suite).

View changes since this review

@rustbot rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Dec 4, 2025
@rustbot
Copy link
Collaborator

rustbot commented Dec 4, 2025

Reminder, once the PR becomes ready for a review, use @rustbot ready.

@rustbot rustbot added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Dec 4, 2025
@dianne
Copy link
Contributor

dianne commented Dec 4, 2025

Also, could you change the PR description? #147875 on its own doesn't allow destructors to access freed memory, it doesn't allow for the creation of dangling references, and I'm at least not aware of a safety guarantee that it violates. You should only get unsoundness out of it if you write unsafe code on the assumption that the borrow checker will enforce the relative drop order of locals that may have destructors and those that definitely don't. Of course, per language team decision, consistent drop order is a promise Rust would like to make. But it's not quite the same as the borrow-checker failing to ensure places outlive their references.

@sladyn98
Copy link
Contributor Author

sladyn98 commented Dec 5, 2025

So what i did was write this simple rust program panic drop.rs

 //@ compile-flags: -C no-prepopulate-passes

#![crate_type = "lib"]

#[no_mangle]
pub fn function_with_drops() {

    let _a = String::from("first");
    let _b = String::from("second");
    let _c = String::from("third");
    might_panic();
}

#[inline(never)]
pub fn might_panic() {
    // This might panic
    panic!()
}

I ran the llvm to get the intermediate representaion and on looking at the IR I cannot find any llvm.lifetime.end statements suggesting to us that on master the StorageDead statements are missing, which according to my understanding means that the borrowchecker does not know when the storage becomes invalid. Let me now write the UI test to see what is up

@dianne
Copy link
Contributor

dianne commented Dec 5, 2025

StorageDead is indeed not present there on the main branch, but that doesn't create a soundness hole in the borrow-checker; those locals are simply treated as being maybe live until the end of the stack frame, so it's technically sound for destructors on the unwind path to reference them. When unwinding, the stack frame will be popped anyway, so we don't need to hint to llvm that the memory's no longer in use. The issue is that we'd like to be more strict in the borrow-checker, both for consistency and so that unsafe code can rely on drop order being enforced.

edit: adjusted wording

@sladyn98 sladyn98 force-pushed the fix-panic-drop-ordering-rebased branch from 5afe7c2 to 59a7e56 Compare January 30, 2026 09:32
@rustbot rustbot added the F-explicit_tail_calls `#![feature(explicit_tail_calls)]` label Jan 30, 2026
@rustbot

This comment has been minimized.

@rustbot

This comment has been minimized.

@sladyn98 sladyn98 requested a review from dianne January 30, 2026 09:32
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jan 30, 2026
@rust-log-analyzer

This comment has been minimized.

Copy link
Contributor

@dianne dianne left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This still needs CI to pass before I can review it properly. I've left a few comments on obvious things, but I don't think reviewing the code changes would be helpful at this point. Please test your changes locally. You don't have to run the whole test suite yourself, but for this change, you'll at least want make sure that the mir-opt and codegen tests all pass, that any relevant ui tests pass, and that tidy passes as well.

Could you rebase onto a more recent commit, also? I don't expect there will be conflicts in the MIR building part of this, but I'm not sure about the rest.

I don't mean to be harsh, but this is a relatively complex and nuanced change. If you're not familiar with what's being changed, why it's being changed, the consequences/needs of that, and general contribution procedure, I'd recommend gaining familiarity with easier issues instead.

View changes since this review

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 30, 2026
@sladyn98 sladyn98 force-pushed the fix-panic-drop-ordering-rebased branch from 59a7e56 to 44fbdb3 Compare February 1, 2026 00:14
@rustbot
Copy link
Collaborator

rustbot commented Feb 1, 2026

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

@rustbot

This comment has been minimized.

@rustbot

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@sladyn98 sladyn98 force-pushed the fix-panic-drop-ordering-rebased branch from e94d041 to 67a9bdb Compare February 1, 2026 09:11
@rustbot

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

Copy link
Contributor

@dianne dianne left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a full review, but I took a glance through the code and comment changes. I think there's some incorrect logic causing the r-a build failure and some suspicious checks papering over it in other cases. I'll take a closer look once CI passes.

View changes since this review

Comment on lines 1995 to 2001
// Only adjust if the drop matches what unwind_to is pointing to (since we process
// drops in reverse order, unwind_to might not match the current drop).
if storage_dead_on_unwind
&& unwind_to != DropIdx::MAX
&& unwind_drops.drop_nodes[unwind_to].data.local == drop_data.local
&& unwind_drops.drop_nodes[unwind_to].data.kind == drop_data.kind
{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This feels suspicious. I think this would need a lot more justification to turn those asserts into conditions, so I have a feeling something is wrong and this is papering over it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unwind_to should always match when processing a Value drop, If it doesn't, we should advance through any interleaved StorageDead/ForLint drops first, The conditional check hides this by silently skipping the adjustment. The conditional check hides the mismatch, but, unwind_to can point to drops from other scopes
We may skip advancing unwind_to when it should advance. This can desync the unwind tree

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, the real problem is diverge_cleanup_target builds the unwind tree in forward order across multiple scopes and build_scope_drops processes one scope's drops in reverse order.
unwind_to can point to a different drop type (StorageDead/ForLint) when processing a Value drop, or vice versa.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One of the approaches i can think of is when processing a drop, if unwind_to doesn't match, walk forward in the unwind tree until we find a matching drop.

Comment on lines 2084 to 2088
let unwind_drop = self
.scopes
.unwind_drops
.add_drop(drop_node.data, unwind_indices[drop_node.next]);
unwind_indices.push(unwind_drop);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this should be unconditional. We only want to add StorageDeads if there's a real (or for-fcw) drop, and maybe ideally only before the last of those (if it's not too complicated). Not sure, but this might be what's causing the problem building r-a, since that involves breaking from a loop.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally there should be some way to write all of this without requiring duplicated logic all over the place. It feels really fragile to have to know in several different parts of that file exactly when unwind drops should be added.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another option to keep it simple would be to always include StorageDeads when building the MIR, then get rid of empty cleanup paths in a post-borrowck pass. I'm not sure how much worse for perf that would be, but we could try profiling it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lets do one thing, ill make the changes, make sure the tests pass and then lets do a profile. Its better to get a sanity check that the changes look good in a first pass. We can always go back and forth on the design and improvments. Lets get the sanity and structure right first.

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 1, 2026
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From your commit message:

This fixes compilation errors that are blocking CI, though these are
pre-existing issues unrelated to the StorageDead changes.

I guess this breakage comes from this PR rather than pre-existing, as this isn't failing in other PRs?

@rust-bors

This comment has been minimized.

This commit fixes several issues related to StorageDead and ForLint drops:

1. Add StorageDead and ForLint drops to unwind_drops for all functions
   - Updated diverge_cleanup_target to include StorageDead and ForLint drops
     in the unwind_drops tree for all functions (not just coroutines), but only
     when there's a cleanup path (i.e., when there are Value or ForLint drops)
   - This ensures proper drop ordering for borrow-checking on panic paths

2. Fix break_for_tail_call to handle StorageDead and ForLint drops
   - Don't skip StorageDead drops for non-drop types
   - Adjust unwind_to pointer for StorageDead and ForLint drops, matching
     the behavior in build_scope_drops
   - Only adjust unwind_to when it's valid (not DropIdx::MAX)
   - This prevents debug assert failures when processing drops in tail calls

3. Fix index out of bounds panic when unwind_to is DropIdx::MAX
   - Added checks to ensure unwind_to != DropIdx::MAX before accessing
     unwind_drops.drop_nodes[unwind_to]
   - Only emit StorageDead on unwind paths when there's actually an unwind path
   - Only add entry points to unwind_drops when unwind_to is valid
   - This prevents panics when there's no cleanup needed

4. Add test for explicit tail calls with StorageDead drops
   - Tests that tail calls work correctly when StorageDead and ForLint drops
     are present in the unwind path
   - Verifies that unwind_to is correctly adjusted for all drop kinds

These changes make the borrow-checker stricter and more consistent by ensuring
that StorageDead statements are emitted on unwind paths for all functions when
there's a cleanup path, allowing unsafe code to rely on drop order being enforced
consistently.
- Add StorageDead to unwind paths for all functions (not just coroutines)
- Modify CleanupPostBorrowck to remove StorageDead from cleanup blocks
- Add tests for the fix and StorageDead removal
When processing drops in reverse order, unwind_to might not point to
the current drop. Only adjust unwind_to when the drop matches what
unwind_to is pointing to, rather than asserting they must match.
Fix lifetime issues in rust-analyzer where automaton doesn't live long
enough for op.union(). Move op declaration inside each match arm to
ensure proper lifetime scope.

This fixes compilation errors that are blocking CI, though these are
pre-existing issues unrelated to the StorageDead changes.
When processing drops in reverse order, unwind_to might not point to the
current drop. Make the unwind_to adjustment conditional on the drop matching,
matching the behavior in build_scope_drops. This prevents assertion failures
when unwind_to points to a different drop than the one being processed.
- Remove conditional logic and optimization from diverge_cleanup_target
- Remove conditional logic from build_exit_tree
- Always add StorageDead when there are Value/ForLint drops
- Cleanup passes (CleanupPostBorrowck, RemoveNoopLandingPads) handle removal
- Fixes reviewer comments about code duplication and fragility
@sladyn98 sladyn98 force-pushed the fix-panic-drop-ordering-rebased branch from 49c1d6a to e4790cd Compare February 9, 2026 03:32
@rustbot
Copy link
Collaborator

rustbot commented Feb 9, 2026

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.

@sladyn98
Copy link
Contributor Author

sladyn98 commented Feb 9, 2026

@dianne Thanks for the first pass review. I addressed most of the comments here. Let me try and get the tests passing and a general structure right. We can then go over any more design and profiling stuff later on.

@rust-log-analyzer

This comment has been minimized.

@sladyn98 sladyn98 force-pushed the fix-panic-drop-ordering-rebased branch from d8a1764 to 2ed7b45 Compare February 9, 2026 05:55
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@sladyn98 sladyn98 force-pushed the fix-panic-drop-ordering-rebased branch from e6b9a18 to 1556a29 Compare February 9, 2026 08:05
@rust-log-analyzer

This comment has been minimized.

Simplify boolean expressions in scope.rs to fix clippy::needless_bool
lint failures, and update test expectations for dropck_trait_cycle_checked
and ctfe-arg-bad-borrow to match new StorageDead behavior.
@sladyn98 sladyn98 force-pushed the fix-panic-drop-ordering-rebased branch from 1556a29 to 44b8dda Compare February 10, 2026 07:34
@rust-log-analyzer
Copy link
Collaborator

The job aarch64-gnu-llvm-20-1 failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)
##[group]Runner Image Provisioner
Hosted Compute Agent
Version: 20260123.484
Commit: 6bd6555ca37d84114959e1c76d2c01448ff61c5d
Build Date: 2026-01-23T19:41:17Z
Worker ID: {cde9b95c-cd71-4266-9e57-8a4bf045ca69}
Azure Region: southcentralus
##[endgroup]
##[group]VM Image
- OS: Linux (arm64)
- Source: Partner
- Name: Ubuntu 24.04 by Arm Limited
---
REPOSITORY                                   TAG       IMAGE ID       CREATED       SIZE
ghcr.io/dependabot/dependabot-updater-core   latest    afc745c7535d   2 weeks ago   783MB
=> Removing docker images...
Deleted Images:
untagged: ghcr.io/dependabot/dependabot-updater-core:latest
untagged: ghcr.io/dependabot/dependabot-updater-core@sha256:faae3d3a1dedd24cde388bb506bbacc0f7ed1eae99ebac129af66acd8540c84a
deleted: sha256:afc745c7535da1bb12f92c273b9a7e9c52c3f12c5873714b2542da259c6d9769
deleted: sha256:64e147d5e54d9be8b8aa322e511cda02296eda4b8b8d063c6a314833aca50e29
deleted: sha256:5cba409bb463f4e7fa1a19f695450170422582c1bc7c0e934d893b4e5f558bc6
deleted: sha256:cddc6ebd344b0111eaab170ead1dfda24acdfe865ed8a12599a34d338fa8e28b
deleted: sha256:2412c3f334d79134573cd45e657fb6cc0abd75bef3881458b0d498d936545c8d
---
test [ui] tests/ui/abi/abi-sysv64-register-usage.rs ... ignored, ignored when the architecture is aarch64
test [ui] tests/ui/abi/abi-typo-unstable.rs#feature_enabled ... ok
test [ui] tests/ui/abi/abi-typo-unstable.rs#feature_disabled ... ok
test [ui] tests/ui/abi/anon-extern-mod.rs ... ok
test [ui] tests/ui/abi/avr-sram.rs#disable_sram ... ok
test [ui] tests/ui/abi/avr-sram.rs#has_sram ... ok
test [ui] tests/ui/abi/arm-unadjusted-intrinsic.rs#aarch64 ... ok
test [ui] tests/ui/abi/avr-sram.rs#no_sram ... ok
test [ui] tests/ui/abi/arm-unadjusted-intrinsic.rs#arm ... ok
test [ui] tests/ui/abi/bad-custom.rs ... ok
test [ui] tests/ui/abi/c-stack-as-value.rs ... ok
test [ui] tests/ui/abi/c-zst.rs#aarch64-darwin ... ok
test [ui] tests/ui/abi/c-zst.rs#powerpc-linux ... ok
---
test [ui] tests/ui/asm/aarch64/may_unwind.rs ... ok
test [ui] tests/ui/asm/aarch64/ttbr0_el2.rs ... ok
test [ui] tests/ui/asm/aarch64/type-check-3.rs ... ok
test [ui] tests/ui/asm/aarch64/type-check-2.rs ... ok
test [ui] tests/ui/asm/aarch64v8r.rs#hf ... ok
test [ui] tests/ui/asm/aarch64/sym.rs ... ok
test [ui] tests/ui/asm/aarch64v8r.rs#r82 ... ok
test [ui] tests/ui/asm/aarch64/type-f16.rs ... ok
test [ui] tests/ui/asm/aarch64v8r.rs#sf ... ok
test [ui] tests/ui/asm/bad-template.rs#aarch64 ... ok
test [ui] tests/ui/asm/binary_asm_labels.rs ... ignored, only executed when the architecture is x86_64
test [ui] tests/ui/asm/arm-low-dreg.rs ... ok
test [ui] tests/ui/asm/asm-with-nested-closure.rs ... ok
test [ui] tests/ui/asm/cfg.rs#reva ... ignored, only executed when the architecture is x86_64
---
test [ui] tests/ui/const-generics/occurs-check/unused-substs-3.rs ... ok
test [ui] tests/ui/const-generics/occurs-check/unused-substs-5.rs ... ok
test [ui] tests/ui/const-generics/ogca/basic-fail.rs ... ok
test [ui] tests/ui/const-generics/occurs-check/unused-substs-4.rs ... ok
test [ui] tests/ui/const-generics/ogca/basic.rs ... ok
test [ui] tests/ui/const-generics/ogca/rhs-but-not-root.rs ... ok
test [ui] tests/ui/const-generics/ogca/coherence-ambiguous.rs ... ok
test [ui] tests/ui/const-generics/opaque_types.rs ... ok
test [ui] tests/ui/const-generics/opaque_types2.rs ... ok
test [ui] tests/ui/const-generics/outer-lifetime-in-const-generic-default.rs ... ok
test [ui] tests/ui/const-generics/overlapping_impls.rs ... ok
test [ui] tests/ui/const-generics/params-in-ct-in-ty-param-lazy-norm.rs#full ... ok
---
test [ui] tests/ui/extern/issue-64655-extern-rust-must-allow-unwind.rs#fat2 ... ok
test [ui] tests/ui/extern/issue-64655-extern-rust-must-allow-unwind.rs#fat3 ... ok
test [ui] tests/ui/extern/issue-80074.rs ... ok
test [ui] tests/ui/extern/issue-95829.rs ... ok
test [ui] tests/ui/extern/lgamma-linkage.rs ... ok
test [ui] tests/ui/extern/no-mangle-associated-fn.rs ... ok
test [ui] tests/ui/extern/not-in-block.rs ... ok
test [ui] tests/ui/extern/unsized-extern-derefmove.rs ... ok
test [ui] tests/ui/extern/windows-tcb-trash-13259.rs ... ok
test [ui] tests/ui/feature-gates/allow-features-empty.rs ... ok
---
test [ui] tests/ui/feature-gates/feature-gate-macro-derive.rs ... ok
test [ui] tests/ui/feature-gates/feature-gate-macro-metavar-expr-concat.rs ... ok
test [ui] tests/ui/feature-gates/feature-gate-marker_trait_attr.rs ... ok
test [ui] tests/ui/feature-gates/feature-gate-may-dangle.rs ... ok
test [ui] tests/ui/feature-gates/feature-gate-mgca-type-const-syntax.rs ... ok
test [ui] tests/ui/feature-gates/feature-gate-min_const_fn.rs ... ok
test [ui] tests/ui/feature-gates/feature-gate-min-generic-const-args.rs ... ok
test [ui] tests/ui/feature-gates/feature-gate-movrs_target_feature.rs ... ignored, only executed when the architecture is x86_64
test [ui] tests/ui/feature-gates/feature-gate-more-maybe-bounds.rs ... ok
test [ui] tests/ui/feature-gates/feature-gate-naked_functions_rustic_abi.rs ... ignored, only executed when the architecture is x86_64
---
test [ui] tests/ui/imports/ambiguous-7.rs ... ok
test [ui] tests/ui/imports/ambiguous-import-visibility-module.rs ... ok
test [ui] tests/ui/imports/ambiguous-8.rs ... ok
test [ui] tests/ui/imports/ambiguous-glob-vs-expanded-extern.rs ... ok
test [ui] tests/ui/imports/ambiguous-panic-glob-vs-multiouter.rs ... ok
test [ui] tests/ui/imports/ambiguous-panic-globvsglob.rs ... ok
test [ui] tests/ui/imports/ambiguous-panic-no-implicit-prelude.rs ... ok
test [ui] tests/ui/imports/ambiguous-panic-non-prelude-core-glob.rs ... ok
test [ui] tests/ui/imports/ambiguous-panic-non-prelude-std-glob.rs ... ok
test [ui] tests/ui/imports/ambiguous-panic-pick-core.rs ... ok
test [ui] tests/ui/imports/ambiguous-panic-pick-std.rs ... ok
---
failures:

---- [mir-opt] tests/mir-opt/async_drop_live_dead.rs stdout ----
45 
46     bb3 (cleanup): {
47         nop;
+         nop;
48         goto -> bb5;
49     }
50 


thread '[mir-opt] tests/mir-opt/async_drop_live_dead.rs' panicked at src/tools/compiletest/src/runtest/mir_opt.rs:84:21:
Actual MIR output differs from expected MIR output /checkout/tests/mir-opt/async_drop_live_dead.a-{closure#0}.coroutine_drop_async.0.panic-unwind.mir
stack backtrace:
   8: __rustc::rust_begin_unwind
             at /rustc/9b1f8ff42d110b0ca138116745be921df5dc97e7/library/std/src/panicking.rs:689:5
   9: core::panicking::panic_fmt
             at /rustc/9b1f8ff42d110b0ca138116745be921df5dc97e7/library/core/src/panicking.rs:80:14
  10: <compiletest::runtest::TestCx>::run_revision
  11: compiletest::runtest::run
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
---- [mir-opt] tests/mir-opt/async_drop_live_dead.rs stdout end ----
---- [mir-opt] tests/mir-opt/coroutine_drop_cleanup.rs stdout ----
37     }
38 
39     bb5 (cleanup): {
+         nop;
40         goto -> bb4;
41     }
42 


thread '[mir-opt] tests/mir-opt/coroutine_drop_cleanup.rs' panicked at src/tools/compiletest/src/runtest/mir_opt.rs:84:21:
Actual MIR output differs from expected MIR output /checkout/tests/mir-opt/coroutine_drop_cleanup.main-{closure#0}.coroutine_drop.0.panic-unwind.mir
stack backtrace:
   8: __rustc::rust_begin_unwind
             at /rustc/9b1f8ff42d110b0ca138116745be921df5dc97e7/library/std/src/panicking.rs:689:5
   9: core::panicking::panic_fmt
             at /rustc/9b1f8ff42d110b0ca138116745be921df5dc97e7/library/core/src/panicking.rs:80:14
  10: <compiletest::runtest::TestCx>::run_revision
  11: compiletest::runtest::run
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
---- [mir-opt] tests/mir-opt/coroutine_drop_cleanup.rs stdout end ----
---- [mir-opt] tests/mir-opt/coroutine_storage_dead_unwind.rs stdout ----
36         StorageLive(_7);
37         StorageLive(_8);
38         _8 = move _3;
-         _7 = take::<Foo>(move _8) -> [return: bb2, unwind: bb9];
+         _7 = take::<Foo>(move _8) -> [return: bb2, unwind: bb10];
40     }
41 
42     bb2: {

45         StorageLive(_9);
46         StorageLive(_10);
47         _10 = move _4;
-         _9 = take::<Bar>(move _10) -> [return: bb3, unwind: bb10];
+         _9 = take::<Bar>(move _10) -> [return: bb3, unwind: bb9];
49     }
50 
51     bb3: {

58 
59     bb4: {
60         StorageDead(_3);
-         drop(_1) -> [return: bb5, unwind: bb12];
+         drop(_1) -> [return: bb5, unwind: bb14];
62     }
63 
64     bb5: {

69         StorageDead(_6);
70         StorageDead(_5);
71         StorageDead(_4);
-         drop(_3) -> [return: bb7, unwind: bb13];
+         drop(_3) -> [return: bb7, unwind: bb15];
73     }
74 
75     bb7: {

76         StorageDead(_3);
-         drop(_1) -> [return: bb8, unwind: bb12];
+         drop(_1) -> [return: bb8, unwind: bb14];
78     }
79 
80     bb8: {

82     }
83 
84     bb9 (cleanup): {
-         goto -> bb10;
+         StorageDead(_10);
+         StorageDead(_9);
+         goto -> bb12;
86     }
87 
88     bb10 (cleanup): {

90     }
91 
92     bb11 (cleanup): {
-         drop(_1) -> [return: bb12, unwind terminate(cleanup)];
+         StorageDead(_8);
+         StorageDead(_7);
+         goto -> bb12;
94     }
95 
96     bb12 (cleanup): {

-         resume;
+         StorageDead(_4);
+         goto -> bb13;
98     }
99 
100     bb13 (cleanup): {

-         drop(_1) -> [return: bb12, unwind terminate(cleanup)];
+         StorageDead(_3);
+         drop(_1) -> [return: bb14, unwind terminate(cleanup)];
+     }
+ 
+     bb14 (cleanup): {
+         resume;
+     }
+ 
+     bb15 (cleanup): {
+         StorageDead(_3);
+         drop(_1) -> [return: bb14, unwind terminate(cleanup)];
102     }
103 }
104 


thread '[mir-opt] tests/mir-opt/coroutine_storage_dead_unwind.rs' panicked at src/tools/compiletest/src/runtest/mir_opt.rs:84:21:
Actual MIR output differs from expected MIR output /checkout/tests/mir-opt/coroutine_storage_dead_unwind.main-{closure#0}.StateTransform.before.panic-unwind.mir
stack backtrace:
   8: __rustc::rust_begin_unwind
             at /rustc/9b1f8ff42d110b0ca138116745be921df5dc97e7/library/std/src/panicking.rs:689:5
   9: core::panicking::panic_fmt
             at /rustc/9b1f8ff42d110b0ca138116745be921df5dc97e7/library/core/src/panicking.rs:80:14
  10: <compiletest::runtest::TestCx>::run_revision
  11: compiletest::runtest::run
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
---- [mir-opt] tests/mir-opt/coroutine_storage_dead_unwind.rs stdout end ----
---- [mir-opt] tests/mir-opt/inline_coroutine_body.rs stdout ----
263 +     }
264 + 
265 +     bb11 (cleanup): {
+ +         StorageDead(_22);
+ +         StorageDead(_19);
+ +         StorageDead(_23);
+ +         StorageDead(_21);
+ +         StorageDead(_18);
+ +         StorageDead(_17);
+ +         StorageDead(_12);
266 +         drop((((*_32) as variant#3).0: ActionPermit<'_, T>)) -> [return: bb12, unwind terminate(cleanup)];
267 +     }
268 + 


thread '[mir-opt] tests/mir-opt/inline_coroutine_body.rs' panicked at src/tools/compiletest/src/runtest/mir_opt.rs:84:21:
Actual MIR output differs from expected MIR output /checkout/tests/mir-opt/inline_coroutine_body.run2-{closure#0}.Inline.panic-unwind.diff
stack backtrace:
   8: __rustc::rust_begin_unwind
             at /rustc/9b1f8ff42d110b0ca138116745be921df5dc97e7/library/std/src/panicking.rs:689:5
   9: core::panicking::panic_fmt
             at /rustc/9b1f8ff42d110b0ca138116745be921df5dc97e7/library/core/src/panicking.rs:80:14

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

F-explicit_tail_calls `#![feature(explicit_tail_calls)]` S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-rust-analyzer Relevant to the rust-analyzer team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Local variable deallocated out of order in the panic path?

6 participants