Refine and extend tests for function signatures #301
Conversation
rossberg
commented
Jun 27, 2016
rossberg
commented
- Extend call_indirect test to check that signature is nominal.
- Avoid use of implicit signatures in call_indirect.wast tests.
- Add tests to func.wast to verify correct implicit signature desugaring.
|
It seems rather odd and surprising to "reuse" function signatures in this way. Why not just create a new signature when one is not specified? In practice this will just matter for small tests anyhow. |
|
I'd be fine with changing it, although that would create rather pathological type sections with lots of redundancy. Deferring to @lukewagner, since he implemented this. |
|
Incidentally, design/#682 just changed AstSemantics.md#calls to have structural equality of function signatures (motivated by dynamic linking which would otherwise need some first-class notion of type that had to be imported/exported so it could be nominally equal). There is not special case for "nominal when intra-module, structural when inter-module", so I think we should spec and test the opposite of what's in this PR. |
|
PTAL. Removed the checks for nominal type tests, now superseded by #314. |
|
Looks like this PR still adds tests that "reuse" function signatures implicitly, which as discussed above seems rather confusing. In the discussion above I don't see any objections to not doing that? |
|
To be more clear, what I'm proposing is to not merge the changes left in this PR. And #314 changes checks to be structural which is great. |
|
Well, we should have tests for the desugaring, and we need to agree what the desugaring is. With |
|
Ok, fair enough. |
|
(lgtm) |
This change updates exception object allocation, initialization, and construction for exnref; as well as dealing with exception propagation from invoking exported functions; throwing exceptions from host functions into wasm; and wrapping and unwrapping JS exceptions as they propagate into and out of wasm.
As discussed in #202 The JS tag was added to the JS API spec in #301, but it is not observable. This change exposes it on the WebAssembly namespace, allowing it to be imported into wasm modules. This allows wasm modules to explicitly extract the thrown JS objects as externrefs from the caught exrefs, and also to throw fresh exceptions with externref payloads that will propagate into JS and can be caught as bare JS objects not wrapped in a WebAssembly.Exception. It also places the restriction that WebAssembly.Exception objects cannot be created with the JS tag, because it would result in ambiguity or asymmetry when such objects unwind from JS into wasm and back out.
