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.