Implement recover for wasm architecture

[Vilsol]

recover was implemented for most architectures in #2331, however wasm was left out.

As suggested here

tinygo/compiler/defer.go

Lines 29 to 33 in 4c64784

	case "wasm32":
	// Probably needs to be implemented using the exception handling
	// proposal of WebAssembly:
	// https://github.com/WebAssembly/exception-handling
	return false

it should probably utilize the proposed exception handling: https://github.com/WebAssembly/exception-handling

Opened as per expected closure of #891

[codefromthecrypt]

Few points which could lead to a better description and possibly another way out.

Summarizing the technical concern

There are a mix of opinions and technical concerns in the 60+ comments in the PR preceding this. It would be nice to have a summary here about what is a technical constraint vs a cultural disinterest in defer.

blocking on incomplete WebAssembly proposals

While some land faster than others, blocking on WebAssembly proposals can prevent implementation for periods of a year or more. The good news is that the proposal mentioned here is at least in phase 3, so it is more likely a when vs if, though it is possible still to be canceled before "finished".

https://github.com/WebAssembly/proposals

How do others get by?

I tried the test data in normal go GOARCH=wasm GOOS=js and it works, all the defer cases. A quick point on why it works in Go and why it working there has no impact to the design here could help.

[atdiar]

To add a use-case, when compiling with the go compiler, it allows us to recover from panics by displaying a relevant message in the browser.

[aykevl]

I tried the test data in normal go GOARCH=wasm GOOS=js and it works, all the defer cases. A quick point on why it works in Go and why it working there has no impact to the design here could help.

You are correct, but note that the Go toolchain emits very different WebAssembly than TinyGo does. And as a result, TinyGo often makes much smaller binaries. I haven't really looked into how it works to be honest, but can't think of a way to implement recover without many changes to the compiler for a feature that is going to be relatively short-lived (the exception handling proposal is certainly the better way to implement recover).

We implemented goroutines using a big giant hack called Asyncify. We can maybe do the same for defer/recover, although the cost/benefit ratio seems far higher for recover.

While some land faster than others, blocking on WebAssembly proposals can prevent implementation for periods of a year or more. The good news is that the proposal mentioned here is at least in phase 3, so it is more likely a when vs if, though it is possible still to be canceled before "finished".

While frustrating, I think this is the most reasonable way forward. Correct me if I'm wrong, though. I'd love to have recover properly supported on all platforms.
If you want to speed this up, please try to get exception handling implemented in wasmtime because that's an important VM that doesn't support it yet: bytecodealliance/wasmtime#3427
There is also wasmer that also lacks support: wasmerio/wasmer#3100

[magic-akari]

Hi there, I'm reaching out to kindly inquire if there have been any recent developments or updates regarding this matter.

Considering that we're now in 2024 and exception handling is nearly a standard feature in mainstream browsers, I'm curious to know if there have been any changes or advancements in TinyGo's implementation of recover for the WASM target.

Thank you for your attention to this, and I look forward to any information you can provide.

[abourget]

Got caught by a recover call too.. do you guys have an idea if/when this would be solved?

[aykevl]

I have implemented recover for WebAssembly. I'll need to clean up the code and then I can make a PR.
But note:

• It requires the WebAssembly exception handling proposal to be implemented. This isn't implemented on wasmtime for example.
• It doesn't work with asyncify, so -scheduler=none is required for this to work. So it only works when goroutines are disabled. This is a limitation of Asyncify, see: Support Asyncify + Try-Catch [Can't build web-gphoto2 with -fwasm-exceptions instead of -fexceptions] WebAssembly/binaryen#4470

EDIT: see #4380