Build with wasm exception handling

[hoodmane]

For now, we need to use a custom rust toolchain for this. Apparently all alternatives to this don't work. -Zbuild-std doesn't work with panic=abort (rust-lang/cargo#7359)
and my attempts to use a custom sysroot with either https://github.com/RalfJung/rustc-build-sysroot/ or https://github.com/DianaNites/cargo-sysroot/ seem to hit the same problem as with -Zbuild-std. Thus, I think the only reasonable way to go is to build the sysroot from the rust source directory. Perhaps we can eventually approach this by copying the lib/rustlib/wasm32-unknown-emscripten/lib/ folder out of the build of the rust compiler on top of a nightly install of the compiler. For now, there is the additional problem that we need this patch to fix unwind=abort:
rust-lang/rust#135450

I got my copy of the rust compiler by checking out this commit: hoodmane/rust@052ba16 two commits ahead of the rust main branch and running:

./x build --stage 2 --target x86_64-unknown-linux-gnu,wasm32-unknown-emscripten

[ryanking13]

Thanks for dealing with rust issues. I think we need some more discussion on how to support custom Rust toolchains.

Instead of hard-coding the values in the code, it would be nice to make this configurable, using pyproject.toml and pyodide config

Also, adding a new subcommand that can install some build tools, including rust toolchain can be useful IMO. There was an open issue about it (pyodide/pyodide#3287).

[hoodmane]

This also only works for x86-linux. I think what I have to do is build the rust compiler from source, then upload the emscripten static libraries folder, then use rustup to install a nightly, then manually add our build-from-source static libraries.

[hoodmane]

But for that to work, we have to wait first for a nightly with rust-lang/rust#135450.

[ryanking13]

Another question is, when can we remove the custom rust toolchain and use the upstream one? I am okay with maintaining the rust toolchain and custom sysroot for a while, but I don't think we can do that forever. So it would be nice to keep track of the blockers.

Could you please open an issue that lists the blockers and their progress that needs to be resolved for the wasm exception handling?

[hoodmane]

The plan is that we roll out wasm exception handling, check that there are no show stoppers, and then rust switches to using it by default after giving other people a chance to comment if it would cause them trouble.

[hoodmane]

Once Rust turns it on by default, we can in principle use the normal Rust toolchain, with the one concern being that it could have abi mismatches due to being compiled with a different Emscripten version than we link with.

See the relevant MCP here:
rust-lang/compiler-team#801

[hoodmane]

I'll open tracking issues for the left over problems when we merge this.

[hoodmane]

Also, @ryanking13 presumably we need to support both the pyodide_2025_0_wasm32 abi and the pyodide_2024_0_wasm32 at the same time? So I'll have to rework this a bit before merging to ensure this. Then we can merge this when the downstream pyodide/pyodide PR is ready and make a release and then all the externally built packages can be rebuilt and then they can be reenabled.

[hoodmane]

Though I don't know if we want to make the Emscripten updates at the same time or just have a 2025_0 ABI with just wasm eh and a 2025_1 ABI with wasm eh plus Emscripten updates. Then the released ABI will use 2025_1.

[hoodmane]

Currently the only extra commit I need on top of the Rust main branch to make the appropriate toolchain is this:
hoodmane/rust@81389fd

[ryanking13]

Though I don't know if we want to make the Emscripten updates at the same time or just have a 2025_0 ABI with just wasm eh and a 2025_1 ABI with wasm eh plus Emscripten updates. Then the released ABI will use 2025_1.

Maybe let's do both updates and call it 2025_0.