Split memory64 JS API tests into separate files#2026
Conversation
Part of WebAssembly#1950, similarly to what was done with the memory64 core tests
|
Alternatively this could go into a separate directory to more strictly mirror the core tests... |
|
Is there any other proposal that did it this way for the js-api tests? Why single out memory64? |
|
If there are others, it would make sense to do those too. I just started with memory64 because there's an interop proposal for memory64, so this is just to make it easier to specify which tests belong to that. |
Ms2ger
left a comment
Ms2ger
left a comment
There was a problem hiding this comment.
I'm mildly negative about it - the design of testharness.js should be sufficient to track subtests if needed, but I won't block if you're convinced this is necessary.
|
Same here, I'm kind of neutral, but if its needed to the interop 26 proposal then so be it! |
|
The interop proposal is the most-direct cause of me wanting to work on this proposal in particular, but |
| test(() => { | ||
| const argument = { "element": "anyfunc", "address": "i64", "initial": 5n }; | ||
| const table = new WebAssembly.Table(argument); | ||
| assert_equal_to_array(table, nulls(5), "before", "i64"); |
There was a problem hiding this comment.
function nulls should have been copied into this file, see the beginning of grow.any.js. This test currently fails:
ReferenceError: nulls is not defined
at Test.<anonymous> (test/wasm-js/tests/table/grow-memory64.any.js:8:25)
4 participants
Part of #1950, similarly to what was done with the memory64 core tests