Heejin Ahn

> hmm what happened in CI? That means your test doesn't pass. Can you check locally and fix it? You can use `test/core/run.py`, or run the interpreter on individual files...

> > +1 on adding tests for `try` + `br`. But the spec tests may not necessarily need to fire the wasm2c bug? If our purpose is testing a `br`...

> Bump -- it would be nice if these tests (or something like them) landed. It looks like @SoniEx2 has responded to the feedback. Sorry for the delays. But I...

Sorry that this slipped from my notice and ended up not being merged for a long time. Can you fix the conflicts so we can merge this?

Given that the old (Phase 3) proposal still has not been deprecated, I think it wouldn't hurt to merge this. By the way the legacy tests have moved into https://github.com/WebAssembly/exception-handling/tree/main/test/legacy/exceptions,...

I think we can write the corresponding tests for the new proposal too. Will add them if @SoniEx2 or anyone submits PRs for them.

> I don't have any particular concerns about the implementation here. We could pack/unpack the exception in a `WA.Exception` at the JS/Wasm boundary as suggested, but I think modifying the...

What do we do for exported functions that return s128 function return types? Do we disallow it or do we trap? I guess we can do the same for `getArg`..

@keithw > Thinking about how we'd implement `exnref` in wasm2c, honestly I think we'd probably just represent is as a fixed-size value type on the stack (probably a struct that...

@conrad-watt > I think this specific concern is something that could be addressed by the variant of Option A that @titzer mentioned, where the existing "exnref-less" `catch` is maintained alongside...