This repository was archived by the owner on Nov 3, 2021. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 24
Invalid JavaScript tests for multi-value functions #44
Comments
Thanks for this bug report! I see the same issue. I was able to fix this with a relatively simple change to the -function assert_return(action, expected) {
+function assert_return(action, ...expected) {
let actual = action();
- if (!Object.is(actual, expected)) {
- throw new Error("Wasm return value " + expected + " expected, got " + actual);
- };
+ if (actual === undefined) {
+ actual = [];
+ } else if (!Array.isArray(actual)) {
+ actual = [actual];
+ }
+ if (actual.length !== expected.length) {
+ throw new Error(expected.length + " value(s) expected, got " + actual.length);
+ }
+ for (let i = 0; i < actual.length; ++i) {
+ if (!Object.is(actual[i], expected[i])) {
+ throw new Error("Wasm return value " + expected[i] + " expected, got " + actual[i]);
+ };
+ }
} One concern is that the multi-value repo does not include the upstream changes to It's tempting to merge that PR as-is, and fix on head. But I suppose the right way to do it is to merge from |
binji
added a commit
that referenced
this issue
Apr 8, 2020
This change modifies `assert_return`. After the Wasm function is invoked, the result will either be `undefined`, a JS `Number`, or a JS `Array`. It's simpler to treat them all as an array, with `undefined` representing an empty array, and `Number` representing an array with one element. We don't check for `Number` here, since as soon as we add support for the reference-types proposal, a scalar result may be an `Object` too. Fixes issue #44.
binji
added a commit
that referenced
this issue
Apr 9, 2020
This change modifies `assert_return`. After the Wasm function is invoked, the result will either be `undefined`, a JS `Number`, or a JS `Array`. It's simpler to treat them all as an array, with `undefined` representing an empty array, and `Number` representing an array with one element. We don't check for `Number` here, since as soon as we add support for the reference-types proposal, a scalar result may be an `Object` too. Fixes issue #44.
Fixed in #45. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
At the WebAssembly/JavaScript boundary, multi-values are converted to JS Arrays according to the spec text. This is not taken into account in the generated JS tests, where
assert_return
still expects exactly two scalar arguments. Seetest/core/_output/if.js:167
for example:assert_return(() => call($1, "multi", [0]), 9, -1)
The JS Array
[9, -1]
is the expected result of the WebAssembly function, butassert_return
will discard its third argument and compare the array with9
.The text was updated successfully, but these errors were encountered: