Turn emscripten-wasm-eh unwinding ABI on by default

[hoodmane]

Proposal

This is a followup to #801.

Emscripten has two different ABIs for stack unwinding, an older one that uses JS exception handling, and a newer one that uses wasm exception handling. The new ABI is used for the wasm32-wasi and wasm32-unknown targets, but currently we only support using the JS eh ABI for wasm32-emscripten. The wasm eh ABI generates smaller, faster, more correct code so it's desirable to switch to it. However, we should add a permanently unstable flag to aid downstream projects in the transition.

The new ABI leads to different IR, different object files, and different linker arguments. Since the object files change it requires a separate build of the standard library. But the change is transparent to Rust/C++/C code.

We had the following plan:

• Rust gains unstable flag to select new ABI
• Pyodide updates to use a version of Rust that has the unstable flag
• Pyodide switches to using new ABI and starts passing the flag
• We solicit other Emscripten target users to see if anyone has concerns about this flag
• Rust turns the flag on by default
• Rust removes support for the old ABI and the flag

Here I am proposing to do the next step in this plan and turn the flag on by default. Specifically, the proposal is to merge this pull request:
rust-lang/rust#147224

The full proposed diff is as follows:

--- a/compiler/rustc_session/src/options.rs
+++ b/compiler/rustc_session/src/options.rs
@@ -2307,7 +2307,7 @@ pub(crate) fn parse_align(slot: &mut Option<Align>, v: Option<&str>) -> bool {
         "emit a section containing stack size metadata (default: no)"),
     emit_thin_lto: bool = (true, parse_bool, [TRACKED],
         "emit the bc module with thin LTO info (default: yes)"),
-    emscripten_wasm_eh: bool = (false, parse_bool, [TRACKED],
+    emscripten_wasm_eh: bool = (true, parse_bool, [TRACKED],
         "Use WebAssembly error handling for wasm32-unknown-emscripten"),
     enforce_type_length_limit: bool = (false, parse_bool, [TRACKED],
         "enforce the type length limit when monomorphizing instances in codegen"),

The feedback we got from target users

The flag is working great in Pyodide. We are successfully compiling a large number of Rust projects with good result. It is a big pain to get the appropriate sysroot though. This proposal would improve things a lot.

We requested feedback on this proposal on the Emscripten repository in April and received only positive feedback:
emscripten-core/emscripten#24058
There is also some discussion here:
rust-lang/rust#112195

The only project that indicated concerns was godot-rust:
godot-rust/gdext#1119
They got loading errors when they tried building with -Z emscripten-wasm-eh. I investigated and found that the problem was that the main Godot runtime was linked without support for exceptions. I was able to fix the problem by building with panic=abort. The Godot runtime is linked with support for wasm exception based longjmp, so if they ever do support panics it will require -Z wasm-emscripten-eh so in my view this proposal is beneficial to godot-rust.

Mentors or Reviewers

@workingjubilee was the second for #801, maybe they would be willing again for this one. I have not asked.

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member who is knowledgeable in the area can second by writing @rustbot second or kickoff a team FCP with @rfcbot fcp $RESOLUTION.
  • Refer to Proposals, Approvals and Stabilization docs for when a second is sufficient, or when a full team FCP is required.
• Once an MCP is seconded, the Final Comment Period begins.
  • Final Comment Period lasts for 10 days after all outstanding concerns are solved.
  • Outstanding concerns will block the Final Comment Period from finishing. Once all concerns are resolved, the 10 day countdown is restarted.
  • If no concerns are raised after 10 days since the resolution of the last outstanding concern, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

[rustbot]

Important

This issue is not meant to be used for technical discussion. There is a Zulip stream for that.
Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

Concerns or objections can formally be registered here by adding a comment.

@rustbot concern reason-for-concern
<description of the concern>

Concerns can be lifted with:

@rustbot resolve reason-for-concern

See documentation at https://forge.rust-lang.org

cc @rust-lang/compiler