Unstable flag to choose Emscripten unwinding abi

[hoodmane]

Proposal

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.

rust-lang/rust#131830 is a draft PR that switches Emscripten from using the old ABI to the new ABI.

I would like to introduce for a period of time an unstable flag to select the unwinding ABI. The reason for this is so that projects using the old ABI can have a transition period. I maintain Pyodide which currently uses the old ABI. When I last attempted to switch to the new ABI, Rust was the only blocker. However, it would be nice to update in these:

1. Rust gains unstable flag to select new ABI
2. Pyodide updates to use a version of Rust that has the unstable flag
3. Pyodide switches to using new ABI and starts passing the flag
4. Rust removes support for the old ABI and the flag
5. Pyodide updates this version of Rust and drops the flag

In particular, separating the step where we update Rust and the step where we switch on the flag allows us to distinguish better between regressions caused by a new Rust version vs regressions caused specifically by the exception handling ABI. Also, if it turns out there is a problem with the new ABI, it allows us to use new versions of Rust with the old ABI while we fix the problems.

Mentors or Reviewers

@workingjubilee?

Process

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

• File an issue describing the proposal.
• A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

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.

[rustbot]

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 to the proposal should be discussed on Zulip and formally registered here by adding a comment with the following syntax:

@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 @rust-lang/compiler-contributors

[workingjubilee]

@rustbot second

[apiraino]

@rustbot label -final-comment-period +major-change-accepted