Derek Schuff

Yes, I think that's basically what I meant. In the current spec we are extracting the externaddr exception object from opaqueData, (meaning the core machinery is tracking that identity for...

I looked a little harder at the current version and realized that we are already storing the exception's identity (in the form of the JS exception object) in the `map`...

> I don't see this in this PR or the overview, but is it intended for `exn` to be passable to/from JS through params/results, or be like `v128` and cause...

I think this PR is now reasonably correct and self-contained according to the description in OP. I think it correctly (although may not yet completely) implements what we discussed in...

> But this algorithm is invoked from another one that already describes Wasm semantics, not host semantics. So we're morally "inside Wasm". So what I'd suggest is to say something...

I'm going to go ahead and land this so I can rebase #269 and do some more cleanups. @aheejin let me know if you have more comments, we can update...

Regarding your numbered points 1-4 about the JS tag: This is not the behavior that the current spec has (or that engines currently implement) e.g. currently we specify that the...

> Is this still relevant? If not, can we close this? It's not relevant for shipping exnref to phase4. We do still have the appendix with the "legacy" format. I...

Another possibility for the place to specify this would be the Web API spec (as opposed to the JS API spec) since as @rossberg mentioned, it's only relevant in JS...

Support was recently added to Binaryen, but hasn't been added to LLVM yet.