Remove -Zoom=panic

[bjorn3]

There are major questions remaining about the reentrancy that this allows. It doesn't have any users on github outside of a single project that uses it in a panic=abort project to show backtraces. It can still be emulated through #[alloc_error_handler] or set_alloc_error_hook depending on if you use the standard library or not. And finally it makes it harder to do various improvements to the allocator shim.

This also adds support for showing backtraces on the first call of the libstd alloc error handler to satisfy the needs of this single project on github that uses it and because it seems generally useful to have. If an allocation while printing the backtrace fails, we don't try to print another backtrace as that will never succeed.

With this PR the sole remaining symbol in the allocator shim that is not effectively emulating weak symbols is the symbol that prevents skipping the allocator shim on stable even when it would otherwise be empty because libstd + #[global_allocator] is used.

Based on #147718 for conflict reasons.

Closes #43596
Fixes #126683

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

[rustbot]

r? @lcnr

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

[RalfJung]

Cc @rust-lang/wg-allocators

[kornelski]

I've been waiting for oom=panic to stabilize!!!

At Cloudflare we were waiting for ability to use it in servers. It was part of the RFC https://github.com/rust-lang/rfcs/blob/master/text/2116-alloc-me-maybe.md#user-profile-server. We currently aren't only because we use stable Rust, and have a ton of hacks in place already put in due to suffering from lack of this feature. In some places we do rely on panics from allocators not being totally UB any more.

Is removal of oom=panic removing just the convenience option, or is the goal to forbid unwinding on allocation failures completely? Will it be allowed to panic in alloc_error_handler or in global allocator functions? (and have it unwind whenever possible instead of always aborting?)

[bjorn3]

You can still panic in the alloc error hook you register with std::alloc::set_alloc_error_hook with this PR (or the #[alloc_error_handler] if you don't use libstd). Any stabilization of this is blocked on the same reentrancy soundness questions as -Zoom=panic. The only allocation errors that set_alloc_error_hook doesn't cover that -Zoom=panic does is for allocations in code running before user code runs, but panics there can't be recovered from anyway.

[bjorn3]

You can still panic in the alloc error hook you register with std::alloc::set_alloc_error_hook with this PR

In fact I changed the existing -Zoom=panic test to test this behavior: tests/ui/panics/alloc_error_hook-unwind.rs