Disable WASM_LEGACY_EXCEPTIONS by default

[sbc100]

The Wasm committee and browser vendors would like legacy wasm exceptions
to be phased out ASAP. To that end this change disables
WASM_LEGACY_EXCEPTIONS by default for users of -fwasm-exceptions.

User who need to target old browsers can obviously set
-sWASM_LEGACY_EXCEPTIONS still.

Running ./emcc -fwasm-exceptions with EMCC_DEBUG=1 shows the effect
this has on min browser versions:

feature_matrix:DEBUG: Enabling MIN_CHROME_VERSION=137 to accommodate Wasm exceptions (-fwasm-exceptions with -sWASM_LEGACY_EXCEPTIONS=0)
feature_matrix:DEBUG: Enabling MIN_FIREFOX_VERSION=131 to accommodate Wasm exceptions (-fwasm-exceptions with -sWASM_LEGACY_EXCEPTIONS=0)
feature_matrix:DEBUG: Enabling MIN_SAFARI_VERSION=180400 to accommodate Wasm exceptions (-fwasm-exceptions with -sWASM_LEGACY_EXCEPTIONS=0)
feature_matrix:DEBUG: Enabling MIN_NODE_VERSION=241500 to accommodate Wasm exceptions (-fwasm-exceptions with -sWASM_LEGACY_EXCEPTIONS=0)

[sbc100]

CC @tlively @dschuff as per out lunch discussion.

[kripken]

Does this change cause minimum browser versions to rise silently (aside for EMCC_DEBUG logging), or does it force the user to set higher browser versions?

[sbc100]

Does this change cause minimum browser versions to rise silently (aside for EMCC_DEBUG logging), or does it force the user to set higher browser versions?

I causes the min browser versions to silently rise, just like opting into any other feature.

This was true both before and after this change, but the extent of the rise is increased by this change.

[kripken]

Does this change cause minimum browser versions to rise silently (aside for EMCC_DEBUG logging), or does it force the user to set higher browser versions?

I causes the min browser versions to silently rise, just like opting into any other feature.

This was true both before and after this change, but the extent of the rise is increased by this change.

Yes, I guess what is surprising here is that the user is still passing in the same -fwasm-exceptions flag but now it is causing more version-limited output.

Maybe the changelog mention is all we need, but let's mention this explicitly? I.e. This means that using -fwasm-exceptions will generate output that requires newer versions of browsers, compared to the same flag in earlier releases

[aheejin]

The Wasm committee and browser vendors would like legacy wasm exceptions to be phased out ASAP.

What's the context? Was there any discussion that prompted this somewhere?

I'm happy if we can pull this off, but I'm worried whether the new thing is as well tested as the old EH, because the adoption rate so far was very low.

[sbc100]

The Wasm committee and browser vendors would like legacy wasm exceptions to be phased out ASAP.

What's the context? Was there any discussion that prompted this somewhere?

This was the outcome of face2face disucssion with @tlively where we talking about how emscripten was still generating legacy wasm-eh programs by default.

Don't you think it makes sense that we generate new EH by default?

[aheejin]

The Wasm committee and browser vendors would like legacy wasm exceptions to be phased out ASAP.

What's the context? Was there any discussion that prompted this somewhere?

This was the outcome of face2face disucssion with @tlively where we talking about how emscripten was still generating legacy wasm-eh programs by default.

Don't you think it makes sense that we generate new EH by default?

Yeah the only concern is it was not used much anywhere so far, so we don't know whether it is well tested. It might break people. But maybe it's the only way to force people to try it? 🤷🏻

[kleisauke]

I think this is still too early, given the current browser support in https://caniuse.com/wf-wasm-exnref-exceptions.

My comment at #24058 (comment) may also still be relevant here. The situation has changed somewhat, though: the necessary V8 fixes have since been backported to Node.js 22 and 24 via PR nodejs/node#62783 and nodejs/node#62567, respectively.

/cc @hoodmane regarding the comment in #24058 (reply in thread).

[sbc100]

I think this is still too early, given the current browser support in https://caniuse.com/wf-wasm-exnref-exceptions.

Can you explain what you mean by this?

This PR only effect users who pass -fwasm-exceptions so they are already opting into this new feature. And they can still opt into -sWASM_LEGACY_EXCEPTION of course. The idea is that we don't want to be increasing the proliferation of the usage of legacy exceptions, unless a user explicitly requires it.

My comment at #24058 (comment) may also still be relevant here. The situation has changed somewhat, though: the necessary V8 fixes have since been backported to Node.js 22 and 24 via PR nodejs/node#62783 and nodejs/node#62567, respectively.

/cc @hoodmane regarding the comment in #24058 (reply in thread).

[kleisauke]

Can you explain what you mean by this?

Sorry, I meant to reply to this:

[...] browser vendors would like legacy wasm exceptions to be phased out ASAP.

As long as the legacy Wasm exception handling proposal remains opt-in and supported, I have no problem with it. However, I read that sentence as suggesting that browser vendors would also like to remove support for legacy Wasm EH, which would be problematic for projects like WordPress (which uses wasm-vips since version 7.1). Also, Wasm EH with exnref is not part of any Baseline target.

[sbc100]

Can you explain what you mean by this?

Sorry, I meant to reply to this:

[...] browser vendors would like legacy wasm exceptions to be phased out ASAP.

As long as the legacy Wasm exception handling proposal remains opt-in and supported, I have no problem with it. However, I read that sentence as suggesting that browser vendors would also like to remove support for legacy Wasm EH, which would be problematic for projects like WordPress (which uses wasm-vips since version 7.1). Also, Wasm EH with exnref is not part of any Baseline target.

Yes, the goal is just to try to stem the flow of new projects using the legacy exceptions, but choosing good defaults in emscripten. I don't see is removing support for legacy exceptions for a long time to come.

[dschuff]

Yes, to be clear we would not be removing support for generating legacy exceptions in Emscripten anytime soon, this is just about defaults. The part about browser vendors is relevant because plenty of Emscripten users do use the defaults, and today if they use EH they are putting more legacy-EH-using binaries out onto the web that might be there forever; we'd rather have fewer of those in the world. Any decision to remove EH from browser engines (or alternatives like using a builtin polyfill or optimizing performance for new EH, etc) would be separate, and based on usage in the wild.

Regarding Baseline, the 3 major browser engines shipped exnref in 2025, so I guess that means it should have been in Baseline 2025. Caniuse says it's not supported in Edge yet, but I wonder if that's bad data; I don't know of any other cases where Edge didn't ship a JS or wasm feature that was on by default in V8.

[kleisauke]

Great! I'm wondering whether this should also be done in LLVM, i.e. -wasm-use-legacy-eh should probably default to false there as well:

emscripten/tools/building.py

Lines 120 to 123 in 618713f

	if settings.WASM_LEGACY_EXCEPTIONS:
	args += ['-wasm-use-legacy-eh']
	else:
	args += ['-wasm-use-legacy-eh=0']

https://github.com/llvm/llvm-project/blob/4741357dac8516be26afbabefa69a8ff6db7334a/llvm/lib/Target/WebAssembly/WebAssemblyTargetMachine.cpp#L73-L81

Otherwise, this could break parity with Rust, since you also need to pass -Cllvm-args=-wasm-use-legacy-eh=0 there. That said, Rust only uses stable LLVM releases (afaik), so it takes a while for changes like this to propagate there.

Regarding Edge, you're right, it seems to be outdated. It looks like it was removed in PR mdn/browser-compat-data#26532, but visiting https://collector.openwebdocs.org/tests/webassembly/exceptionsFinal locally with Edge 151.0.4129.107 seems to work just fine.

[dschuff]

Yeah it probably makes sense to also flip the default in LLVM. Aside from matching Rust (and Emscripten), most users using bare LLVM apart from Emscripten are targeting non-web engines, many of which (such as Wasmtime) don't support legacy exceptions anyway.

[kleisauke]

Regarding Edge, you're right, it seems to be outdated. It looks like it was removed in PR mdn/browser-compat-data#26532, but visiting https://collector.openwebdocs.org/tests/webassembly/exceptionsFinal locally with Edge 151.0.4129.107 seems to work just fine.

This was fixed in commit mdn/browser-compat-data@777082f and propagated to web-features in commit web-platform-dx/web-features@5b1c9da (meaning it is now part of Baseline 2025). I expect the following pages to be updated within the next couple of days:
https://webstatus.dev/features/wasm-exnref-exceptions
https://caniuse.com/wf-wasm-exnref-exceptions