Skip to content
This repository was archived by the owner on Nov 3, 2021. It is now read-only.

Invalid JavaScript tests for multi-value functions #44

Closed
thibaudmichaud opened this issue Apr 6, 2020 · 2 comments
Closed

Invalid JavaScript tests for multi-value functions #44

thibaudmichaud opened this issue Apr 6, 2020 · 2 comments

Comments

@thibaudmichaud
Copy link

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. See test/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, but assert_return will discard its third argument and compare the array with 9.

@binji
Copy link
Member

binji commented Apr 8, 2020

Thanks for this bug report! I see the same issue. I was able to fix this with a relatively simple change to the assert_return function:

-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 assert_return that combines the NaN checking too (see WebAssembly/spec#1104). At the same time, there is a pending merge from the multi-value repo back to the upstream spec (see WebAssembly/spec#1145).

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 spec to multi-value, fix the bug here, then update the PR with this fix.

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.
@Ms2ger
Copy link
Contributor

Ms2ger commented Jun 19, 2020

Fixed in #45.

@Ms2ger Ms2ger closed this as completed Jun 19, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants