[guybedford]

This adds the jsapi test suite for WebAssembly including the new ESM Integration jsapi tests from WebAssembly/esm-integration#110 with upstream PR in web-platform-tests/wpt#53718.

Tests for string builtins and namespaceInstance are pending #59020 and #59024 respectively.

[nodejs-github-bot]

Review requested:

• @nodejs/web-standards

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 89.69%. Comparing base (0474a27) to head (0be51d5).
⚠️ Report is 17 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #59034      +/-   ##
==========================================
- Coverage   91.54%   89.69%   -1.86%     
==========================================
  Files         351      692     +341     
  Lines      147748   214167   +66419     
  Branches    23240    41109   +17869     
==========================================
+ Hits       135258   192087   +56829     
- Misses      12236    14145    +1909     
- Partials      254     7935    +7681     

see 463 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[panva]

out/Release/node --experimental-wasm-modules /repo/node/test/wpt/test-wasm-jsapi.mjs
(node:83231) Warning: Failed to load the ES module: /repo/node/test/fixtures/es-modules/globals.js. Make sure to set "type": "module" in the nearest package.json file or use the .mjs extension.
(Use `node --trace-warnings ...` to show where the warning was created)
node:internal/modules/run_main:107
    triggerUncaughtException(
    ^

AssertionError [ERR_ASSERTION]: The expression evaluated to a falsy value:

  ok(e instanceof WebAssembly.CompileError)

    at file:///repo/node/test/wpt/test-wasm-jsapi.mjs:13:3 {
  generatedMessage: true,
  code: 'ERR_ASSERTION',
  actual: false,
  expected: true,
  operator: '==',
  diff: 'simple'
}

/repo/node/test/fixtures/es-modules/globals.js:5
export { i32_value as '🚀i32_value' }
^^^^^^

SyntaxError: Unexpected token 'export'
    at wrapSafe (node:internal/modules/cjs/loader:1762:18)
    at Module._compile (node:internal/modules/cjs/loader:1803:20)
    at Module._extensions..js (node:internal/modules/cjs/loader:1969:10)
    at Module.load (node:internal/modules/cjs/loader:1552:32)
    at Module._load (node:internal/modules/cjs/loader:1354:12)
    at wrapModuleLoad (node:internal/modules/cjs/loader:255:19)
    at loadCJSModuleWithModuleLoad (node:internal/modules/esm/translators:325:3)
    at ModuleWrap.<anonymous> (node:internal/modules/esm/translators:230:7)
    at ModuleJob.run (node:internal/modules/esm/module_job:430:25)
    at async onImport.tracePromise.__proto__ (node:internal/modules/esm/loader:639:26)

[richardlau]

@miladfarca FYI it looks like some of these tests are failing on Linux s390x.

[guybedford]

So, it seems it this is for round-tripping v128:

  [UNEXPECTED_FAILURE][FAIL] v128 globals should work correctly in WebAssembly-to-WebAssembly imports
  assert_equals: expected 1 but got 67108864
      at Test.<anonymous> (/home/iojs/build/workspace/node-test-commit-linuxone/test/fixtures/wpt/wasm/jsapi/esm-integration/mutable-global-sharing.tentative.any.js:52:3)
      at process.processTicksAndRejections (node:internal/process/task_queues:104:5)
  Command: /home/iojs/build/workspace/node-test-commit-linuxone/out/Release/node --experimental-wasm-modules undefined 'esm-integration/mutable-global-sharing.tentative.any.js'

The value returned is consistent with big endian handling of the SIMD path, which formally speaking is a V8 bug since Wasm is supposed to have little endian behaviours.

There is a SIMD test for this in V8, but V8 only runs x390x simulator assuming VECTOR_ENHANCE_FACILITY_2, which might not be available on our hardware?

I've pushed a temporary commit which replicates the internal simd test suite case in question, to see if that also fails on the hardware. If so, then this is a V8 bug on s390x separate to the WPT work here.

[guybedford]

I can confirm the same failure, so this is a v8 bug for Wasm SIMD on s390x - https://ci.nodejs.org/job/node-test-commit-aix/61569/nodes=aix72-power9/testReport/junit/(root)/parallel/test_wasm_simd_global/.

I've added a specific skip for this environment to resolve the issue, given this is not a Node.js or WPT issue.

[richardlau]

I can confirm the same failure, so this is a v8 bug for Wasm SIMD on s390x - https://ci.nodejs.org/job/node-test-commit-aix/61569/nodes=aix72-power9/testReport/junit/(root)/parallel/test_wasm_simd_global/.

FWIW AIX is not Linux s390x, but both are big endian platforms.

[miladfarca]

This patch should fix the issue on big endian (which includes s390x): http://crrev.com/c/7704213

[guybedford]

Unfortunately it seems like that patch did not fix the error in the CI here. Let me know if I should bring back the skip or if we should wait for a further follow-on.

[guybedford]

Oh nvm I misread the commit being shown on this PR as being included here... sorry for confusion will continue with the final CI here further based on the skipped test, to be corrected later.

[richardlau]

This patch should fix the issue on big endian (which includes s390x): http://crrev.com/c/7704213

#62449

[aduh95]

Tests are failing on v24.x-staging with this change, it would require a manual backport PR if we want it on Node.js 24