test: WPT for Wasm jsapi including new ESM Integration tests

[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.68%. Comparing base (a936d89) to head (643faf0).
⚠️ Report is 68 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #59034      +/-   ##
==========================================
+ Coverage   89.67%   89.68%   +0.01%     
==========================================
  Files         676      676              
  Lines      206501   206738     +237     
  Branches    39540    39600      +60     
==========================================
+ Hits       185177   185412     +235     
- Misses      13457    13463       +6     
+ Partials     7867     7863       -4     

see 59 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)

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/71934/

[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.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/71936/

[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.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/71944/

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/71946/

[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.