Don't leak return value after panic in drop

[matthewjasper]

Closes #47949

[rust-highfive]

r? @davidtwco

(rust_highfive has picked a reviewer for you, use r? to override)

[matthewjasper]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit 7acf3f1b0d7330edcc908662e170dd6182074f8f with merge d610dce8ea41761b41e03160a39fca995dea0df5...

[bors]

☀️ Try build successful - checks-actions
Build commit: d610dce8ea41761b41e03160a39fca995dea0df5 (d610dce8ea41761b41e03160a39fca995dea0df5)

[rust-timer]

Queued d610dce8ea41761b41e03160a39fca995dea0df5 with parent b9a94c9, future comparison URL.

[rust-timer]

Finished benchmarking try commit (d610dce8ea41761b41e03160a39fca995dea0df5): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never

[Mark-Simulacrum]

Since this adds code, I suspect it's always going to be a regression. I would ignore the incremental benchmarks here, which brings us down to roughly 5% regression on real world codebases. I think given this is a soundness fix (at least arguably) and certainly unintuitive behavior, we should land this (modulo review of the diff itself, which I have not done).

[davidtwco]

Unsure if this is still only intended for checking perf, but LGTM; someone else should also take a look though.

[davidtwco]

r? @pnkfelix

[pnkfelix]

nominating for discussion at next T-compiler triage meeting.

I am inclined to swallow the compiler performance regression, but I figure we will be better off talking about it as a team. Also, I think it will be best to land this early in the release cycle, i.e. soon after the next beta is cut.

• I know it is a soundness fix, which we would normally prioritize, but I would rather take a little bit more time landing this, and potentially beta-backporting it, than have to deal with reverting it from beta later.

[pnkfelix]

@bors r+ rollup=never

[bors]

📌 Commit 7acf3f1b0d7330edcc908662e170dd6182074f8f has been approved by pnkfelix

[bors]

🔒 Merge conflict

This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again.

How do I rebase?

Assuming self is your fork and upstream is this repository, you can resolve the conflict following these steps:

1. git checkout drop-on-into (switch to your branch)
2. git fetch upstream master (retrieve the latest master)
3. git rebase upstream/master -p (rebase on top of it)
4. Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
5. git push self drop-on-into --force-with-lease (update this PR)

You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial.

Please avoid the "Resolve conflicts" button on GitHub. It uses git merge instead of git rebase which makes the PR commit history more difficult to read.

Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

Error message

Auto-merging compiler/rustc_mir_build/src/build/scope.rs
CONFLICT (content): Merge conflict in compiler/rustc_mir_build/src/build/scope.rs
Auto-merging compiler/rustc_mir_build/src/build/mod.rs
Auto-merging compiler/rustc_mir_build/src/build/matches/mod.rs
CONFLICT (content): Merge conflict in compiler/rustc_mir_build/src/build/matches/mod.rs
Auto-merging compiler/rustc_mir_build/src/build/expr/into.rs
Auto-merging compiler/rustc_mir_build/src/build/expr/as_rvalue.rs
Automatic merge failed; fix conflicts and then commit the result.

[matthewjasper]

@bors r=pnkfelix

[richkadel]

@matthewjasper

FYI, #79109 should (hopefully) land today, and there are new tests that might be affected by this change.

If you can wait until tomorrow, assuming that PR landed, fetch the latest changes into your branch before running with --bless, so it will regenerate the expected results on the most up-to-date tests.

[bors]

☔ The latest upstream changes (presumably #79109) made this pull request unmergeable. Please resolve the merge conflicts.

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

[matthewjasper]

@bors r=pnkfelix

[bors]

📌 Commit 4fef391 has been approved by pnkfelix

[bors]

🌲 The tree is currently closed for pull requests below priority 100, this pull request will be tested once the tree is reopened

[bors]

⌛ Testing commit 4fef391 with merge 9122b76...

[bors]

☀️ Test successful - checks-actions
Approved by: pnkfelix
Pushing 9122b76 to master...