Why support -fwasm-exceptions require exception-handling feature to be set?

[trzeciak]

Hi @RReverser,
I have a question about to support -fwasm-exceptions, initiali it was introduced in this issue: GoogleChromeLabs/wasmbin/issues/7 and implemented in this MR: GoogleChromeLabs/wasmbin/pull/9.
And I came here from this issue: getsentry/symbolicator/issues/969.

I saw that this requires the exception-handling feature to be set, the question is:

Why support -fwasm-exceptions require exception-handling feature to be set?

Could it be because:

• this feature breaks current existing features?
• most people don't need it anyway, so would it unnecessarily increase the binary file size? (I checked and the difference is insignificant)
• or maybe something else?

I would like the symbolicator to handle -fwasm-exceptions by default, so I would like to ask your advice whether it is better to add a declaration of this feature in the symbolicator repo, or maybe it is possible to add it without the flag and upgrade the version in the symbolicator repo.

PS: Thank you for developing this tool, when I saw the error 0xD I couldn't help but laugh → I thought I would have to dig for a long time, but thanks to you everything went smoothly!

[RReverser]

Oh wow, sorry, I missed this entirely as I was on vacation back then.

Basically, any features that are in proposal stage rather than merged into Wasm spec are intentionally kept under Cargo feature flags to note that they might be unstable.

As soon as they are merged into the Wasm spec, it's okay to not require features for them anymore.