Core crate doesn't support panic="abort" in 1.90 wasm32-unknown-emscripten

[curiousdannii]

I'm trying to shrink my WASM output, and wanted to try panic="abort", but I'm getting an error saying that the core crate requires the unwind panic strategy.

Rust version: 1.90.0 (stable)
Target: wasm32-unknown-emscripten

Cargo invocation:

RUSTFLAGS=-Csymbol-mangling-version=v0 cargo build --release --target=wasm32-unknown-emscripten

Compiler output:

   Compiling remglk v0.1.0 (/src/remglk/remglk)
   Compiling remglk_capi v0.1.0 (/src/remglk/remglk_capi)
error: the crate `core` requires panic strategy `unwind` which is incompatible with this crate's strategy of `abort`

error: could not compile `remglk_capi` (lib) due to 1 previous error

In my searches I haven't seen anyone have panic strategy troubles for the core crate before, which I take either means that I'm doing something very weird with my setup, or that wasm32-unknown-emscripten is not used much any more.

I've tested, and panic="abort" did work in 1.89, and it works in 1.90 on x86_64-unknown-linux-gnu. So this seems particular to the Emscripten target, and it's a new regression.

[bjorn3]

Maybe #144225 cc @purplesyringa

[purplesyringa]

Yes, #144225 added the regression. The gist of the situation is as follows.

The reasoning in the original PR was: if core is compiled with -C panic=unwind, it will contain try blocks and throw statements. Therefore, even if the program is compiled with -C panic=abort, the resulting binary will still only work on runtimes that support EH.

At the time, I thought that this change will only affect WASI environments, for which we ship -C panic=abort core. Under these conditions, an unwinding core was opt-in, so it didn't make sense to support this weird combination of users manually configuring core to unwind, but also manually configuring the binary to abort. That convinced me and nikic at the time that this is acceptable. However, this change also affected Emscripten, which we ship an unwinding core for, and it seems neither of us realized that.

Here's the tricky part. core::intrinsics::wasm32::throw is an extern "Rust" function. rustc assumes that, if the panic strategy is abort, Rust functions cannot ever unwind; but throw can. So the error here is completely reasonable: it is possible for an otherwise correct library crate to cause UB by calling throw, if the binary crate is eventually compiled with -C panic=abort, even though the library crate could not have possibly known about who's going to use it.

I think the most straightforward fix is to make throw behave similarly to foreign *-unwind functions, though it's not clear which ABI to use for it. C-unwind, I guess? (Rust-unwind would come in handy, meaning "the ABI is fully controlled by rustc, but don't assume it doesn't unwind when called from -C panic=abort crates".) Then we also need to teach rustc that the call to wasm_throw inside throw shouldn't taint the whole stdarch as -C panic=unwind-only because throw itself is *-unwind. I guess this is something we could patch into required_panic_strategy (i.e. "only check functions with Rust ABI"), but the scope of implications I might not be accounting for makes me uncomfortable.

Alternatively, we could move the intrinsic into the panic runtime. This seems very wrong.

[purplesyringa]

@rustbot label +A-panic -needs-triage +T-compiler +T-libs-api +E-needs-design

[purplesyringa]

Yeah, I think the main problem I'm having implementing this is that we assume that non-extern functions (i.e. those with Rust source available) are guaranteed to be non-unwinding if the binary is compiled under -C panic=abort, which is not the case for throw. It seems like there's currently no way to say "yes, this function has source, but it can still unwind properly, since its code was compiled as part of a -C panic=unwind crate; treat it just like a foreign functions".

[purplesyringa]

I submitted #148269 as a stop-gap fix, but I don't know if it's of sufficient quality.