Unclear intended behavior for using WebAssembly.Exception.getArg to materialize a v128 member in JS

[ddegazio]

Per the current spec, when we call WebAssembly.Exception.getArg, we get a payload from exn_read, and invoke ToJSValue on an element of it.

From the definition of exn_read, the returned element we use for the payload is the field tuple from the exception instance, which is just some number of ordinary WebAssembly values val*.

But, in ToJSValue, we start off with this assertion:

Assert: w is not of the form v128.const v128.

Since v128 is an ordinary WebAssembly value type, it seems valid currently for one to occur in the return tuple of exn_read. But then, getArg funnels that value directly into ToJSValue, violating its invariants. I might be overlooking something? Otherwise, it seems like there should probably be a check for v128 elements in getArg which throws a TypeError.

[dschuff]

Yes, I think you are exactly right. v128 values can't currently be passed to JS, and there are various other places where we throw similar TypeErrors (e.g. the GetGlobalValue algorithm, the parameter conversion steps of "call an Exported Function" and "run a host function") before we invoke ToJSValue. It might make sense to sink that check into ToJSValue itself, but I haven't checked whether there are any places where e.g. we wouldn't be able to throw from there. But assuming we don't do that, then yeah, getArg should have the check, and also the Exception constructor (because ToWebAssemblyValue has a similar assertion). I can make a fix for that.

[dschuff]

Oh oops, it looks like this is the same issue as #295. Guess we just neglected to land the fix then.