Upgrade to upstream d550dd3c808e (module-loader rewrite)

[sosukesuzuki]

Merges upstream WebKit d550dd3c808e into Bun's fork.

Highlights

• [JSC] Rewrite module loader (4a63810) — replaces the JS+C++ hybrid loader with a pure-C++ implementation following the modern ES spec. Adds CyclicModuleRecord, ModuleRegistryEntry, ModuleGraphLoadingState, ModuleLoaderPayload, ModuleLoadingContext, ModuleMap. JSModuleLoader is now a JSCell (was JSNonFinalObject); the registry JSMap is gone.
• [JSC] Remove JSInternalPromise (d36f217) — GlobalObjectMethodTable::moduleLoaderImportModule/Fetch now return JSPromise*; moduleLoaderResolve gains a trailing bool useImportMap.
• 5 new JSType values inserted before ObjectType.

Bun-fork additions in this branch

• VM::m_synchronousModuleLoadingDepth + JSModuleLoader::loadModuleSync: when set, settled-promise reactions in performPromiseThenWithInternalMicrotask / triggerPromiseReactions run inline instead of queueing a microtask. This preserves Bun's synchronous require(esm) semantics on the new pipeline.
• JSModuleLoader::registryEntry/removeEntry/clearAll/moduleMap accessors so Bun can inspect/clear the C++ module map (replaces the old JSMap registry access).
• makeModule: handle SourceProviderSourceType::Synthetic and BunTranspiledModule; report parsed source memory cost to the heap; add an exception check after error.toErrorObject.
• CyclicModuleRecord::initializeEnvironment: ported Bun's TypeScript-import tolerance (ImportEntryType::SingleTypeScript) and Node-style error messages.
• loadModule/moduleLoadTopSettled: preserve the original ScriptFetchParameters across the pipeline so HostDefined import-attribute types don't trip the single-arg create(Type) assert.

The full upstream JSC changelog (47 commits) is in the companion Bun PR description.

[coderabbitai]

Walkthrough

This pull request extensively updates test infrastructure and build configuration. Key changes include replacing conditional memory-limited test skips with explicit memory-hog markers, adding macOS CMake presets, refactoring Xcode configuration variables, introducing comprehensive module and WASM tests, and adding numerous stress test cases for promise tampering, typed array detachment, and YARR JIT scenarios.

Changes

Cohort / File(s)	Summary
Build Configuration CMakeLists.txt, CMakePresets.json, Dockerfile	Updated Swift compiler configuration with defensive re-configure handling; added macOS-specific CMake presets with Ninja generator and CCACHE setup; modified Ubuntu APT repository URL for Docker builds.
Xcode Configuration Cleanup Configurations/CommonBase.xcconfig, Configurations/Sanitizers.xcconfig, Configurations/WebKitTargetConditionals.xcconfig	Removed Xcode version conditionals (WK_XCODE_BEFORE_*, WK_XCODE_*); streamlined Swift memory safety flags; removed code coverage and ASan workaround variables.
Git Plugin Skills .claude/plugins/git-webkit/skills/find/SKILL.md	Narrowed skill usage description from general git operations to specific commit hash appearance in tool results.
Test Directive Standardization JSTests/microbenchmarks/*.js (100+ files), JSTests/slowMicrobenchmarks/*.js, JSTests/stress/*.js (150+ files), JSTests/wasm/*.js	Systematically replaced //@ skip if $memoryLimited with //@ memoryHog! across hundreds of test files; added //@ exclusive! directives to select tests for exclusive execution.
Module System Tests JSTests/modules/bare-resolution-failure.js, JSTests/modules/concurrent-imports.js, JSTests/modules/module-var-resolve-scope-osr-availability-in-async-finally.js, JSTests/modules/sync-from-async.js, JSTests/modules/tla-cycle.js	Added comprehensive tests for bare specifier resolution failures, concurrent module imports, async final blocks with module variables, top-level await cycles, and synchronous access to async module bindings.
Promise and Async Tests JSTests/stress/promise-isPromise.js, JSTests/stress/module-loader-promise-then-*.js (15+ files), JSTests/stress/module-loader-security-*.js (10+ files)	Added Promise.isPromise validation, extensive module loader security tests under Promise.prototype.then tampering, proxy interception, and Object.defineProperty scenarios.
Typed Array and Buffer Tests JSTests/stress/dataview-constructor-bug-311903-*.js, JSTests/stress/typedarray-constructor-bug-311903-*.js, JSTests/stress/array-length-store-ic-*.js	Added regression tests for DataView/TypedArray constructor behavior when ArrayBuffer becomes detached during argument evaluation; array length store IC tests.
WASM Memory64 Spec Tests JSTests/wasm/memory64-spec-tests/*.wast.js (25+ files)	Added comprehensive memory64 specification compliance tests covering address space, alignment, bulk operations, call indirection, floating-point memory, loads/stores, redundancy, trap conditions, table operations, and initialization.
WASM Stress Tests JSTests/wasm/stress/atomic-cmpxchg-large-offset.js, JSTests/wasm/stress/ipint-multimem-oob.js, JSTests/wasm/stress/jspi-stack-traces.js, JSTests/wasm/stress/memory64-*.js	Added atomic operations at large offsets, IPInt multi-memory OOB checks, JSPI stack trace validation, and memory64 atomics/load-store tests.
YARR JIT Regression Tests JSTests/stress/yarr-jit-paren-context-head-uaf.js	Added 362-line regression test for YARR JIT ParenContext use-after-free with multiple backtracking scenarios and capture validation.
Iterator and Promise API Tests JSTests/stress/iterator-prototype-join.js, JSTests/stress/short-circuit-assignment-readonly-local.js	Added Iterator.prototype.join comprehensive coverage and short-circuit assignment operator validation for readonly local bindings.
LEB128 and SIMD Tests JSTests/wasm/ipint-tests/ipint-test-leb-decode.js, JSTests/wasm/ipint-tests/ipint-test-simd-*.js	Added LEB128 decoding validation tests and SIMD memory operation round-trip checks with lane variants.
Test Expectations Updates JSTests/test262/expectations.yaml, JSTests/mozilla/mozilla-tests.yaml, JSTests/wasm.yaml	Removed expectation entries for previously-failing dynamic import and top-level await tests; added exclusive directives to specific Mozilla tests; registered new wasm memory64 spec test suite.
Microbenchmark Additions JSTests/microbenchmarks/array-length-reset-double.js, JSTests/microbenchmarks/json-stringify-int32-array.js, JSTests/microbenchmarks/wasm-udiv-by-constant.js, JSTests/microbenchmarks/large-empty-array-join.js, JSTests/microbenchmarks/typed-array-from-array.js	Added new microbenchmarks for array operations, JSON stringification, WebAssembly division, and typed array construction; marked select tests with exclusive execution directives.
Removed Tests JSTests/microbenchmarks/internal-promise-internal-all.js, JSTests/stress/internal-promise-constructor-not-confusing.js, JSTests/stress/internal-promise-is-not-exposed.js	Deleted internal promise-related tests no longer needed for the public API surface.
WASM Debugger Updates JSTests/wasm/debugger/tests/tests.py	Updated LLDB assertion patterns for dynamic WASM module load notifications from "new wasm module loaded" to "loaded new wasm module with ids: 1".
String Index and Buffer Handling JSTests/microbenchmarks/string-index-of-*.js (30+ files), JSTests/microbenchmarks/string-index-of-*-beg/end/mid/404.js	Reformatted string index-of microbenchmarks with consistent brace/indentation styles and updated memory directives; maintained identical benchmark logic across all variants.

[coderabbitai]

Actionable comments posted: 22

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@CMakeLists.txt`:
- Line 31: The if-statement currently compares the variable CMAKE_Swift_COMPILER
against the literal string "_swift_wrapper" which never matches the intended
variable value; update the comparison to use the value of the _swift_wrapper
variable (i.e., dereference/expand _swift_wrapper in the comparison) so the
cache-poisoning guard actually triggers when CMAKE_Swift_COMPILER equals the
value held in _swift_wrapper.
- Around line 42-43: Add cleanup for the remaining temporary variable by
unsetting _which_retcode alongside the existing unsets for _swift_wrapper and
_real_swiftc; locate the block that calls unset(_swift_wrapper) and
unset(_real_swiftc) and add unset(_which_retcode) so all temporary variables
(_which_retcode, _swift_wrapper, _real_swiftc) are removed after use.

In `@Configurations/CommonBase.xcconfig`:
- Line 124: The OTHER_SWIFT_FLAGS entry currently includes a non-existent
compiler option "-enable-experimental-feature ImportCxxMembersLazily"; remove
that flag from the OTHER_SWIFT_FLAGS assignment (or replace it with the correct,
supported flag if you intended a different Swift C++ interop feature) so the
compiler line containing OTHER_SWIFT_FLAGS no longer references
"-enable-experimental-feature ImportCxxMembersLazily".

In `@JSTests/microbenchmarks/bigint64-array-index-of-small.js`:
- Line 1: The test file bigint64-array-index-of-small.js incorrectly uses the
heavyweight marker "//@ memoryHog!"; remove that marker (or replace it with a
simple skip directive if the test framework requires it) so this small
16-element BigInt64Array test is not classified as a memory hog. Locate the "//@
memoryHog!" token in bigint64-array-index-of-small.js and delete it (or change
it to the appropriate skip/comment directive), leaving the rest of the test (the
array allocation and any "let size = 16" logic) unchanged.

In `@JSTests/microbenchmarks/loop-unrolling-array-clone-big.js`:
- Line 1: Remove the incorrect "memoryHog!" tag from the test header in
JSTests/microbenchmarks/loop-unrolling-array-clone-big.js since the test only
allocates a 20-element array across 10k iterations (negligible memory); replace
it with either no tag or a clarifying comment that "big" refers to
loop-unrolling size rather than data size so the test is not misclassified by
memory-sensitive tooling.

In `@JSTests/microbenchmarks/string-index-of-1001-end.js`:
- Around line 2-6: The bench function currently declares an unused parameter
named "string"; remove this vestigial parameter from the bench(signature) so it
becomes bench(func) and update every call site that passes a label string (e.g.,
bench("label", someFunc)) to pass only the function (e.g., bench(someFunc));
ensure the function body (loop using func) and any references to the old
parameter are adjusted accordingly.

In `@JSTests/modules/concurrent-imports.js`:
- Around line 28-48: The test currently hard-codes a single global interleaving
by comparing logs.join("\n") to the exact expected array, which makes the test
flaky; change the assertion logic (replace the equality check using the expected
array and logs) to validate per-import properties instead: assert there are five
"Starting import N" lines (for N=1..5), assert for each N that "Import N
completed" appears and that an "Access N: someArray,someFunction" follows that
completion (i.e., for each N the completion line index < access line index), and
do not assert any ordering between different N values; use the existing logs
array and the expected labels ("Starting import", "Import N completed", "Access
N: someArray,someFunction") to locate and validate each import’s sequence.

In `@JSTests/modules/concurrent-imports/module.js`:
- Line 1: Replace the host-dependent sleep in module.js: change the line using
await new Promise(r => setTimeout(r, 10)) to a microtask resolution using await
Promise.resolve() so the module uses host-independent async evaluation; ensure
the surrounding module initialization logic (the awaited expression) remains the
same and only the Promise creation is replaced.

In `@JSTests/modules/sync-from-async.js`:
- Around line 3-5: The comment in JSTests/modules/sync-from-async.js
inaccurately states the ReferenceError is "caught and asserted" here; update the
comment to say this file merely triggers module evaluation via import and that
the actual assertion/check is performed in JSTests/modules/sync-from-async/b.js
so triage isn't confused; reference the test file name sync-from-async.js and
the assertion location b.js in the revised wording.

In `@JSTests/modules/tla-cycle.js`:
- Around line 1-7: Replace the two string throws with Error objects: change the
post-import throw "Expected an exception" to throw new Error("Expected an
exception") and change the throw "Incorrect exception message" inside the catch
to throw new Error("Incorrect exception message"); keep the existing catch(e)
check (e.message !== "C failed") unchanged so the code still compares the error
message string.

In `@JSTests/stress/iterator-prototype-includes.js`:
- Line 1: The unscoped skip directive ("//@ skip if $architecture == \"x86_64\"
and $hostOS == \"linux\"") disables the whole stress test for a major platform;
update that directive to be specific or documented: either narrow the condition
to the exact failing configuration (e.g., add additional guards like $buildType,
$compiler, or a specific test flag) or replace/augment the skip with an inline
comment containing a bug/issue tracker ID and explicit removal criteria (what
must be fixed and when to remove the skip) so future reviewers can understand
and remove it when resolved.

In `@JSTests/stress/iterator-prototype-join.js`:
- Around line 111-114: The isDone flag is never updated so assertions on isDone
in this test are ineffective; inside each iterator implementation (the object
with properties value, isClosed, isDone and its next() method) set this.isDone =
true at the point you return a { done: true } result and set this.isDone = false
when the iterator is initialized or when yielding a live value, and ensure any
early-close path (where isClosed is set) also sets this.isDone = true so
assertions referring to isDone will be meaningful (update the next()
implementations and any close/return branches that currently only touch
isClosed).
- Around line 129-134: Replace the manual try/catch blocks that call
iterator.join(Symbol(42)) and assert on the caught error with the test helper
shouldThrow to make the expectation explicit; specifically, call shouldThrow(()
=> iterator.join(Symbol(42)), TypeError, "Cannot convert a symbol to a string")
(or the project's shouldThrow signature) instead of using try/catch + sameValue
checks, and update the second identical block (the other
iterator.join(Symbol(42)) occurrence) the same way to remove duplicated
error-handling code.

In `@JSTests/stress/module-loader-security-deep-chain-tampered.js`:
- Around line 16-17: The leak-detection list stored in the variable types
currently checks for ["JSSourceCode", "ModuleRegistryEntry",
"ModuleLoadingContext", "ModuleGraphLoadingState", "ModuleLoaderPayload"] but
misses the new loader internals; update the types array declaration (variable
name types) to include "ModuleMap" alongside the existing type names so leaks of
ModuleMap are also detected.
- Around line 32-49: The wrapper uses truthiness checks for
onFulfilled/onRejected (wrappedFulfilled and wrappedRejected) which can try to
call non-callable truthy values; change the condition to test callability (e.g.,
typeof onFulfilled === "function" or an existing IsCallable utility) and only
create the wrapper when the handler is callable, otherwise leave
onFulfilled/onRejected untouched; ensure you refer to the same identifiers
(wrappedFulfilled, wrappedRejected, onFulfilled, onRejected) and preserve the
existing logic that inspects describe(...) and isInternalType(...) inside the
wrappers.

In `@JSTests/stress/module-loader-security-failure-tampered.js`:
- Around line 33-49: The wrappers wrappedFulfilled and wrappedRejected currently
decide to wrap based on truthiness of onFulfilled/onRejected which can cause
non-callable truthy values to be invoked; change the guards to test callability
using typeof onFulfilled === "function" and typeof onRejected === "function" so
only actual functions are wrapped and invoked, leaving non-functions unchanged;
keep the existing internal logic that uses describe(...) and isInternalType(...)
to push into leakedValues and return the original handlers when not callable.

In `@JSTests/stress/module-loader-security-reimport-tampered.js`:
- Around line 40-57: The wrapper uses truthy checks when creating
wrappedFulfilled and wrappedRejected which can treat non-callable truthy values
as functions and cause runtime errors; update the conditionals to check
callability with typeof onFulfilled === "function" and typeof onRejected ===
"function" when creating wrappedFulfilled and wrappedRejected (keep the existing
behavior of returning the original onFulfilled/onRejected when not a function),
and ensure the rest of the logic that calls describe, isInternalType, and pushes
into leakedValues remains unchanged.

In `@JSTests/stress/promise-isPromise.js`:
- Line 20: The rejected promise created for the assertion (Promise.reject()) has
no rejection handler and can trigger unhandled-rejection warnings; update the
call used with Promise.isPromise so the rejected promise has a no-op rejection
handler (e.g., attach .catch(() => {}) or equivalent) while preserving the
assertion, referencing the Promise.isPromise and Promise.reject usage so the
test still verifies isPromise(true) but avoids unhandled rejections.

In `@JSTests/stress/yarr-jit-paren-context-head-uaf.js`:
- Around line 8-11: The current shouldBe function uses JSON.stringify for
comparison which collapses undefined to null in arrays and can hide mismatches
of regex capture groups; update shouldBe to perform a strict deep equality check
that preserves undefined (e.g., use Node's assert.deepStrictEqual or implement a
recursive deepEqual that uses === for primitives and compares array lengths and
elements including undefined) and throw the same Error when they differ; modify
the shouldBe function to call that deep-equality routine instead of
JSON.stringify so unmatched capture groups are not treated as equal to null.

In `@JSTests/wasm/stress/ipint-multimem-oob.js`:
- Around line 102-103: The tests currently catch all exceptions (e.g., in the
try around inst.exports.scalarLoad(PAGE - 3)) which can hide unexpected
failures; update each catch block (the ones guarding inst.exports.scalarLoad and
similar OOB ops) to rethrow any error that is not a WebAssembly.RuntimeError by
replacing "catch (e) { }" with "catch (e) { if (!(e instanceof
WebAssembly.RuntimeError)) throw e; }" so only expected WebAssembly runtime
traps are swallowed and other errors surface.

In `@JSTests/wasm/stress/jspi-stack-traces.js`:
- Around line 65-71: The test assumes at least three frames after finding
captureStack but may index past the array; add an explicit length guard on
frames before accessing frames[captureIdx + 1] and frames[captureIdx + 2] (use
frames.length and captureIdx) and assert the stack is long enough with a clear
message referencing capturedStack, captureStack, and frames; only then perform
the existing checks that the subsequent frames include "wasm-function" to avoid
a generic TypeError when the stack is shorter than expected.

In `@JSTests/wasm/stress/memory64-atomics.js`:
- Around line 42-49: The file-level comment incorrectly states the test uses
"memory64 (i64 addresses) with shared memory" while the atomic block uses a
memory32 shared declaration `(memory (export "memory") 1 1 shared)`; either
change that atomic block to a memory64 shared declaration `(memory (export
"memory") i64 1 1 shared)` to match the top comment, or update the file-level
comment to state that the file tests memory64 non-atomic behavior separately and
uses memory32 shared for the atomic block; locate the module with `(memory
(export "memory") 1 1 shared)` and adjust it or edit the top-of-file comment
accordingly.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: b2fd4c6f-c8d9-410f-b4a7-4c5be3500072

📥 Commits

Reviewing files that changed from the base of the PR and between c0eac76 and fce1a0e.

📒 Files selected for processing (300)

• .claude/plugins/git-webkit/skills/find/SKILL.md
• CMakeLists.txt
• CMakePresets.json
• Configurations/CommonBase.xcconfig
• Configurations/Sanitizers.xcconfig
• Configurations/WebKitTargetConditionals.xcconfig
• Dockerfile
• JSTests/microbenchmarks/array-from-derived-object-func.js
• JSTests/microbenchmarks/array-from-object-func.js
• JSTests/microbenchmarks/array-length-reset-double.js
• JSTests/microbenchmarks/bigint64-array-index-of-large.js
• JSTests/microbenchmarks/bigint64-array-index-of-medium.js
• JSTests/microbenchmarks/bigint64-array-index-of-small.js
• JSTests/microbenchmarks/biguint64-array-index-of-large.js
• JSTests/microbenchmarks/biguint64-array-index-of-medium.js
• JSTests/microbenchmarks/biguint64-array-index-of-small.js
• JSTests/microbenchmarks/float32-array-index-of-large.js
• JSTests/microbenchmarks/float32-array-index-of-medium.js
• JSTests/microbenchmarks/float32-array-index-of-small.js
• JSTests/microbenchmarks/float64-array-index-of-large.js
• JSTests/microbenchmarks/float64-array-index-of-medium.js
• JSTests/microbenchmarks/float64-array-index-of-small.js
• JSTests/microbenchmarks/get-private-name.js
• JSTests/microbenchmarks/int32-array-index-of-large.js
• JSTests/microbenchmarks/int32-array-index-of-medium.js
• JSTests/microbenchmarks/int32-array-index-of-small.js
• JSTests/microbenchmarks/internal-promise-internal-all.js
• JSTests/microbenchmarks/jquery-todomvc-regexp.js
• JSTests/microbenchmarks/json-stringify-int32-array.js
• JSTests/microbenchmarks/large-empty-array-join.js
• JSTests/microbenchmarks/loop-unrolling-array-clone-big.js
• JSTests/microbenchmarks/loop-unrolling-array-clone-small.js
• JSTests/microbenchmarks/loop-unrolling-constant-small.js
• JSTests/microbenchmarks/loop-unrolling-variable-large.js
• JSTests/microbenchmarks/loop-unrolling-variable-medium-dep.js
• JSTests/microbenchmarks/loop-unrolling-variable-medium.js
• JSTests/microbenchmarks/loop-unrolling-variable-small.js
• JSTests/microbenchmarks/lots-of-fields.js
• JSTests/microbenchmarks/mul-immediate-sub.js
• JSTests/microbenchmarks/put-by-val-direct-large-index.js
• JSTests/microbenchmarks/set-delete-add.js
• JSTests/microbenchmarks/string-index-of-10000001-404.js
• JSTests/microbenchmarks/string-index-of-10000001-beg.js
• JSTests/microbenchmarks/string-index-of-10000001-end.js
• JSTests/microbenchmarks/string-index-of-10000001-mid.js
• JSTests/microbenchmarks/string-index-of-1000001-404.js
• JSTests/microbenchmarks/string-index-of-1000001-beg.js
• JSTests/microbenchmarks/string-index-of-1000001-end.js
• JSTests/microbenchmarks/string-index-of-1000001-mid.js
• JSTests/microbenchmarks/string-index-of-100001-404.js
• JSTests/microbenchmarks/string-index-of-100001-beg.js
• JSTests/microbenchmarks/string-index-of-100001-end.js
• JSTests/microbenchmarks/string-index-of-100001-mid.js
• JSTests/microbenchmarks/string-index-of-10001-404.js
• JSTests/microbenchmarks/string-index-of-10001-beg.js
• JSTests/microbenchmarks/string-index-of-10001-end.js
• JSTests/microbenchmarks/string-index-of-10001-mid.js
• JSTests/microbenchmarks/string-index-of-1001-404.js
• JSTests/microbenchmarks/string-index-of-1001-beg.js
• JSTests/microbenchmarks/string-index-of-1001-end.js
• JSTests/microbenchmarks/string-index-of-1001-mid.js
• JSTests/microbenchmarks/string-index-of-101-404.js
• JSTests/microbenchmarks/string-index-of-101-beg.js
• JSTests/microbenchmarks/string-index-of-101-end.js
• JSTests/microbenchmarks/string-index-of-101-mid.js
• JSTests/microbenchmarks/string-index-of-11-404.js
• JSTests/microbenchmarks/string-index-of-11-beg.js
• JSTests/microbenchmarks/string-index-of-11-end.js
• JSTests/microbenchmarks/string-index-of-11-mid.js
• JSTests/microbenchmarks/typed-array-from-array.js
• JSTests/microbenchmarks/u16-string-index-of-10000001-404.js
• JSTests/microbenchmarks/u16-string-index-of-10000001-beg.js
• JSTests/microbenchmarks/u16-string-index-of-10000001-end.js
• JSTests/microbenchmarks/u16-string-index-of-10000001-mid.js
• JSTests/microbenchmarks/wasm-udiv-by-constant.js
• JSTests/modules/bare-resolution-failure.js
• JSTests/modules/bare-resolution-failure/a/x.js
• JSTests/modules/bare-resolution-failure/b/y.js
• JSTests/modules/concurrent-imports.js
• JSTests/modules/concurrent-imports/module.js
• JSTests/modules/module-var-resolve-scope-osr-availability-in-async-finally.js
• JSTests/modules/module-var-resolve-scope-osr-availability-in-async-finally/h.js
• JSTests/modules/sync-from-async.js
• JSTests/modules/sync-from-async/a.js
• JSTests/modules/sync-from-async/b.js
• JSTests/modules/tla-cycle.js
• JSTests/modules/tla-cycle/a.js
• JSTests/modules/tla-cycle/b.js
• JSTests/modules/tla-cycle/c.js
• JSTests/mozilla/mozilla-tests.yaml
• JSTests/slowMicrobenchmarks/dense-set.js
• JSTests/slowMicrobenchmarks/function-constructor-with-huge-strings.js
• JSTests/slowMicrobenchmarks/map-constant-key.js
• JSTests/stress/PrintStream-truncation-for-extremely-long-strings.js
• JSTests/stress/StringObject-define-length-getter-rope-string-oom.js
• JSTests/stress/array-buffer-view-watchpoint-can-be-fired-in-really-add-in-dfg.js
• JSTests/stress/array-length-store-ic-double-noncow.js
• JSTests/stress/array-length-store-ic-double-then-int32.js
• JSTests/stress/array-prototype-concat-of-long-spliced-arrays.js
• JSTests/stress/array-prototype-concat-of-long-spliced-arrays2.js
• JSTests/stress/array-reverse-doesnt-clobber.js
• JSTests/stress/array-sink-materialize-cycle-break-in-exit-invalid.js
• JSTests/stress/atob-btoa-oom-check.js
• JSTests/stress/big-int-constructor-oom.js
• JSTests/stress/big-wasm-memory-grow-no-max.js
• JSTests/stress/big-wasm-memory-grow.js
• JSTests/stress/big-wasm-memory.js
• JSTests/stress/bigdecimal-identifiers-fail-on-oom.js
• JSTests/stress/bigint-can-throw-oom.js
• JSTests/stress/bounds-checking-in-cold-loop.js
• JSTests/stress/btoa-string-overflow.js
• JSTests/stress/call-varargs-inlining-should-not-clobber-previous-to-free-register.js
• JSTests/stress/check-is-constant-non-cell-should-not-array-profile-during-osr-exit.js
• JSTests/stress/check-stack-overflow-before-value-profiling-arguments.js
• JSTests/stress/codeblock-destructor-access-unlinkedcodeblock.js
• JSTests/stress/constructFunctionSkippingEvalEnabledCheck-should-throw-out-of-memory-error.js
• JSTests/stress/create-error-out-of-memory-rope-string.js
• JSTests/stress/data-view-byte-length-oob-exit.js
• JSTests/stress/dataview-byte-length-large-array-oob-baseline.js
• JSTests/stress/dataview-byte-length-large-array-oob.js
• JSTests/stress/dataview-byte-length-large-array.js
• JSTests/stress/dataview-constructor-bug-311903-weird-bytelength-detach-buffer.js
• JSTests/stress/dataview-constructor-bug-311903-weird-byteoffset-detach-buffer.js
• JSTests/stress/describe-huge-strings.js
• JSTests/stress/dont-reserve-huge-capacity-lexer.js
• JSTests/stress/eval-huge-big-int-memory-overflow.js
• JSTests/stress/exception-checks-before-and-after-viewwithunderlyingstring.js
• JSTests/stress/exhaust-gigacage-and-allocate-vm.js
• JSTests/stress/fast-stringifier-check-string-length.js
• JSTests/stress/force-string-array-or-string.js
• JSTests/stress/function-name-too-long-to-reify.js
• JSTests/stress/get-array-length-reuse.js
• JSTests/stress/get-own-property-descriptors-oom.js
• JSTests/stress/has-own-property-name-cache-string-keys.js
• JSTests/stress/has-own-property-name-cache-symbol-keys.js
• JSTests/stress/incremental-marking-should-not-dead-lock-in-new-property-transition.js
• JSTests/stress/internal-promise-constructor-not-confusing.js
• JSTests/stress/internal-promise-is-not-exposed.js
• JSTests/stress/intl-canonicalize-locale-list-error-oom.js
• JSTests/stress/intl-data-time-format-string-overflow.js
• JSTests/stress/iterator-prototype-includes.js
• JSTests/stress/iterator-prototype-join.js
• JSTests/stress/joined-strings-should-not-exceed-max-string-length.js
• JSTests/stress/js-fixed-array-out-of-memory.js
• JSTests/stress/json-stringified-overflow-2.js
• JSTests/stress/json-stringified-overflow.js
• JSTests/stress/json-stringify-out-of-memory.js
• JSTests/stress/json-stringify-stack-overflow.js
• JSTests/stress/json-stringify-string-builder-overflow.js
• JSTests/stress/large-string-should-not-crash-error-creation.js
• JSTests/stress/large-unshift-splice.js
• JSTests/stress/literal-parser-error-message-oom.js
• JSTests/stress/make-large-string-jit-strcat.js
• JSTests/stress/make-large-string-jit.js
• JSTests/stress/make-large-string-strcat.js
• JSTests/stress/make-large-string.js
• JSTests/stress/make-rope-overflow-nested-catch.js
• JSTests/stress/make-rope-overflow-nested.js
• JSTests/stress/many-substrings-of-rope-shouldnt-use-excessive-memory.js
• JSTests/stress/map-forEach.js
• JSTests/stress/map-rehash-oom.js
• JSTests/stress/max-typed-array-length-toString.js
• JSTests/stress/missing-exception-check-in-JSValue-toWTFStringSlowCase.js
• JSTests/stress/missing-exception-check-in-json-stringifier-gap.js
• JSTests/stress/module-loader-object-prototype-then-no-promise-tamper.js
• JSTests/stress/module-loader-promise-then-reassigned-same-value.js
• JSTests/stress/module-loader-promise-then-tampered-no-deps.js
• JSTests/stress/module-loader-promise-then-tampered.js
• JSTests/stress/module-loader-security-deep-chain-tampered.js
• JSTests/stress/module-loader-security-defineproperty-then.js
• JSTests/stress/module-loader-security-failure-tampered.js
• JSTests/stress/module-loader-security-proxy-then.js
• JSTests/stress/module-loader-security-reimport-tampered.js
• JSTests/stress/module-loader-security-thenable-namespace-tampered.js
• JSTests/stress/module-loader-security-thenable-namespace.js
• JSTests/stress/module-loader-security-tla-tampered-then.js
• JSTests/stress/numberingSystemsForLocale-cached-strings-should-be-immortal-and-safe-for-concurrent-access.js
• JSTests/stress/operationSwitchCharWithUnknownKeyType-should-avoid-resolving-rope-strings.js
• JSTests/stress/operationSwitchCharWithUnknownKeyType-should-avoid-resolving-rope-strings2.js
• JSTests/stress/out-of-memory-handle-in-join.js
• JSTests/stress/out-of-memory-in-globalFuncUnescape.js
• JSTests/stress/out-of-memory-in-intl-segmenter.js
• JSTests/stress/out-of-memory-making-error-string-in-literal-parser.js
• JSTests/stress/out-of-memory-while-constructing-BytecodeGenerator.js
• JSTests/stress/out-of-memory-while-describing-symbol-for-error.js
• JSTests/stress/own-property-names-oom.js
• JSTests/stress/pretty-print-oom.js
• JSTests/stress/promise-isPromise.js
• JSTests/stress/race-to-add-opaque-roots-in-ConcurrentPtrHashSet.js
• JSTests/stress/re-enter-resolve-rope-string.js
• JSTests/stress/regexp-accumulatedResult-overflow.js
• JSTests/stress/regexp-bol-optimize-out-of-stack.js
• JSTests/stress/regexp-escape-oom.js
• JSTests/stress/regexp-huge-oom.js
• JSTests/stress/regexp-quantify-atom-copy-term-out-of-stack.js
• JSTests/stress/regress-109102631.js
• JSTests/stress/regress-178385.js
• JSTests/stress/regress-185888.js
• JSTests/stress/regress-189132.js
• JSTests/stress/regress-190187.js
• JSTests/stress/regress-191563.js
• JSTests/stress/regress-192717.js
• JSTests/stress/regress-84402043.js
• JSTests/stress/resources/module-loader-promise-then-tampered-dep.js
• JSTests/stress/resources/module-loader-promise-then-tampered-no-deps.js
• JSTests/stress/resources/module-loader-promise-then-tampered-target.js
• JSTests/stress/resources/module-loader-security-deep-a.js
• JSTests/stress/resources/module-loader-security-deep-b.js
• JSTests/stress/resources/module-loader-security-deep-c.js
• JSTests/stress/resources/module-loader-security-thenable-namespace-module.js
• JSTests/stress/resources/module-loader-security-tla-module.js
• JSTests/stress/sampling-profiler-richards.js
• JSTests/stress/scoped-arguments-table-should-be-tolerant-for-oom.js
• JSTests/stress/set-rehash-oom.js
• JSTests/stress/short-circuit-assignment-readonly-local.js
• JSTests/stress/splay-flash-access-1ms.js
• JSTests/stress/splay-flash-access.js
• JSTests/stress/stack-frame-code-block-offset.js
• JSTests/stress/stack-overflow-in-scope-with-catch.js
• JSTests/stress/stack-overflow-regexp.js
• JSTests/stress/stress-agent.js
• JSTests/stress/string-16bit-repeat-overflow.js
• JSTests/stress/string-joining-long-strings-should-not-crash.js
• JSTests/stress/string-overflow-createError-builder.js
• JSTests/stress/string-overflow-createError-fit.js
• JSTests/stress/string-overflow-createError.js
• JSTests/stress/string-overflow-in-dfg-graph-dump.js
• JSTests/stress/string-prototype-replace-should-throw-out-of-memory-error-when-using-too-much-memory.js
• JSTests/stress/string-regexp-replace-oom.js
• JSTests/stress/test-exception-assert-in-ExceptionHelpers-createError.js
• JSTests/stress/test-out-of-memory.js
• JSTests/stress/too-large-base64-string.js
• JSTests/stress/try-get-value-without-gc.js
• JSTests/stress/typed-array-always-large.js
• JSTests/stress/typed-array-eventually-large.js
• JSTests/stress/typed-array-filter-oom.js
• JSTests/stress/typed-array-large-eventually-oob.js
• JSTests/stress/typed-array-large-slice.js
• JSTests/stress/typed-array-oom-in-buffer-accessor.js
• JSTests/stress/typed-array-set.js
• JSTests/stress/typed-array-subarray-can-throw-oom-error.js
• JSTests/stress/typedarray-constructor-bug-311903-weird-bytelength-detach-buffer.js
• JSTests/stress/typedarray-constructor-bug-311903-weird-byteoffset-detach-buffer.js
• JSTests/stress/typedarray-sort-out-of-memory.js
• JSTests/stress/unlinked-code-block-destructor.js
• JSTests/stress/unshiftCountSlowCase-correct-postCapacity.js
• JSTests/stress/v8-deltablue-strict.js
• JSTests/stress/var-injection-cache-invalidation.js
• JSTests/stress/verify-can-gc-node-index.js
• JSTests/stress/watchdog-fire-while-in-forEachInIterable.js
• JSTests/stress/weakblock-trigger-gc.js
• JSTests/stress/yarr-jit-paren-context-head-uaf.js
• JSTests/test262/expectations.yaml
• JSTests/wasm.yaml
• JSTests/wasm/debugger/tests/tests.py
• JSTests/wasm/function-tests/grow-memory-cause-gc.js
• JSTests/wasm/gc/array_new_data.js
• JSTests/wasm/ipint-tests/ipint-test-leb-decode.js
• JSTests/wasm/ipint-tests/ipint-test-simd-memory.js
• JSTests/wasm/ipint-tests/ipint-test-simd-multi-byte-leb.js
• JSTests/wasm/js-api/test_memory_constructor.js
• JSTests/wasm/memory64-spec-tests/address64.wast.js
• JSTests/wasm/memory64-spec-tests/align64.wast.js
• JSTests/wasm/memory64-spec-tests/binary_leb128_64.wast.js
• JSTests/wasm/memory64-spec-tests/bulk64.wast.js
• JSTests/wasm/memory64-spec-tests/call_indirect64.wast.js
• JSTests/wasm/memory64-spec-tests/endianness64.wast.js
• JSTests/wasm/memory64-spec-tests/float_memory64.wast.js
• JSTests/wasm/memory64-spec-tests/load64.wast.js
• JSTests/wasm/memory64-spec-tests/memory64-imports.wast.js
• JSTests/wasm/memory64-spec-tests/memory64.wast.js
• JSTests/wasm/memory64-spec-tests/memory_copy64.wast.js
• JSTests/wasm/memory64-spec-tests/memory_fill64.wast.js
• JSTests/wasm/memory64-spec-tests/memory_grow64.wast.js
• JSTests/wasm/memory64-spec-tests/memory_init64.wast.js
• JSTests/wasm/memory64-spec-tests/memory_redundancy64.wast.js
• JSTests/wasm/memory64-spec-tests/memory_trap64.wast.js
• JSTests/wasm/memory64-spec-tests/table64.wast.js
• JSTests/wasm/memory64-spec-tests/table_copy64.wast.js
• JSTests/wasm/memory64-spec-tests/table_copy_mixed.wast.js
• JSTests/wasm/memory64-spec-tests/table_fill64.wast.js
• JSTests/wasm/memory64-spec-tests/table_get64.wast.js
• JSTests/wasm/memory64-spec-tests/table_grow64.wast.js
• JSTests/wasm/memory64-spec-tests/table_init64.wast.js
• JSTests/wasm/memory64-spec-tests/table_set64.wast.js
• JSTests/wasm/memory64-spec-tests/table_size64.wast.js
• JSTests/wasm/references/multitable.js
• JSTests/wasm/stress/array-element-creation.js
• JSTests/wasm/stress/atomic-cmpxchg-large-offset.js
• JSTests/wasm/stress/block_end_aliasing.js
• JSTests/wasm/stress/block_end_aliasing_2.js
• JSTests/wasm/stress/catch-pinned-registers.js
• JSTests/wasm/stress/enumerator-oom.js
• JSTests/wasm/stress/externref-result-tuple.js
• JSTests/wasm/stress/initialize-100k-functions.js
• JSTests/wasm/stress/inline-simd-function.js
• JSTests/wasm/stress/ipint-multimem-oob.js
• JSTests/wasm/stress/jspi-stack-traces.js
• JSTests/wasm/stress/memory64-atomics.js
• JSTests/wasm/stress/memory64-load-and-store.js

💤 Files with no reviewable changes (5)

• JSTests/stress/internal-promise-is-not-exposed.js
• JSTests/microbenchmarks/internal-promise-internal-all.js
• JSTests/stress/internal-promise-constructor-not-confusing.js
• Configurations/WebKitTargetConditionals.xcconfig
• JSTests/test262/expectations.yaml

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

Missing variable dereference in comparison.

The comparison CMAKE_Swift_COMPILER STREQUAL _swift_wrapper compares against the literal string "_swift_wrapper" rather than the value of _swift_wrapper. This will cause the cache poisoning guard to never trigger, defeating the purpose of this fix.

🐛 Proposed fix

-    if (CMAKE_Swift_COMPILER STREQUAL _swift_wrapper)
+    if (CMAKE_Swift_COMPILER STREQUAL "${_swift_wrapper}")

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	if (CMAKE_Swift_COMPILER STREQUAL _swift_wrapper)
	if (CMAKE_Swift_COMPILER STREQUAL "${_swift_wrapper}")

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@CMakeLists.txt` at line 31, The if-statement currently compares the variable
CMAKE_Swift_COMPILER against the literal string "_swift_wrapper" which never
matches the intended variable value; update the comparison to use the value of
the _swift_wrapper variable (i.e., dereference/expand _swift_wrapper in the
comparison) so the cache-poisoning guard actually triggers when
CMAKE_Swift_COMPILER equals the value held in _swift_wrapper.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Incomplete cleanup of temporary variables.

_which_retcode is created on line 32 but not unset along with the other temporary variables.

🧹 Proposed fix

     unset(_swift_wrapper)
     unset(_real_swiftc)
+    unset(_which_retcode)

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	unset(_swift_wrapper)
	unset(_real_swiftc)
	unset(_swift_wrapper)
	unset(_real_swiftc)
	unset(_which_retcode)

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@CMakeLists.txt` around lines 42 - 43, Add cleanup for the remaining temporary
variable by unsetting _which_retcode alongside the existing unsets for
_swift_wrapper and _real_swiftc; locate the block that calls
unset(_swift_wrapper) and unset(_real_swiftc) and add unset(_which_retcode) so
all temporary variables (_which_retcode, _swift_wrapper, _real_swiftc) are
removed after use.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🌐 Web query:

Swift ImportCxxMembersLazily experimental feature status

💡 Result:

No evidence found of an experimental Swift compiler feature named "ImportCxxMembersLazily". Searches across Swift GitHub repositories, official documentation, evolution proposals, and compiler option definitions (FrontendOptions.td) returned no matches for this exact flag. Related findings: - Lazy C++ member importing was implemented in 2021 via PR #38675 ("Lazily import members of clang namespaces and records via requests"), merged without an associated experimental flag. - Recent C++ interop experimental flags exist, e.g., "ImportNonPublicCxxMembers" (PR #79728, merged March 2025). - Lazy importing enhancements for import-as-member in PRs #71320 and #72023 (2024), with workaround flag "-disable-named-lazy-import-as-member-loading". - Current C++ interop enabled via "-cxx-interoperability-mode=default" (no "ImportCxxMembersLazily"). The feature appears to be enabled by default in modern Swift (post-Swift 5.9 C++ interop support) without a specific toggle, or the name may be incorrect/misremembered.

Citations:

• 1: [cxx-interop] Lazily import members of clang namespaces and records via requests. swiftlang/swift#38675
• 2: [cxx-interop] Make experimental flag ImportNonPublicCxxMembers swiftlang/swift#79728
• 3: https://github.com/apple/swift/blob/main/include/swift/Option/FrontendOptions.td
• 4: Add workaround flag for lazy import-as-member swiftlang/swift#72023
• 5: [ClangImporter] Support lazy member loading for import-as-member globals in extensions swiftlang/swift#71320
• 6: https://github.com/swiftlang/swift/blob/36b5090a/include/swift/Option/FrontendOptions.td
• 7: https://www.swift.org/documentation/cxx-interop/status
• 8: https://swift.org/documentation/cxx-interop/project-build-setup/

---

Remove the non-existent -enable-experimental-feature ImportCxxMembersLazily flag.

The flag does not exist in Swift's compiler options. This will likely cause build failures or silent ignorance by the compiler. If lazy C++ member importing was intended, it is enabled by default in modern Swift's C++ interop support (post-Swift 5.9). Remove this flag or replace it with the correct flag name if a specific feature was intended.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@Configurations/CommonBase.xcconfig` at line 124, The OTHER_SWIFT_FLAGS entry
currently includes a non-existent compiler option "-enable-experimental-feature
ImportCxxMembersLazily"; remove that flag from the OTHER_SWIFT_FLAGS assignment
(or replace it with the correct, supported flag if you intended a different
Swift C++ interop feature) so the compiler line containing OTHER_SWIFT_FLAGS no
longer references "-enable-experimental-feature ImportCxxMembersLazily".

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Incorrect memoryHog! classification for small array.

This test allocates only a 16-element BigInt64Array (~128 bytes). The memoryHog! marker is inappropriate here—this is the "small" variant and has minimal memory footprint. Consider reverting to a simple skip directive or removing the memory-related marker entirely.

🔍 Verification: Compare with medium/large variants

#!/bin/bash
# Description: Check array sizes across the indexOf benchmark family

rg -n "let size = " JSTests/microbenchmarks/bigint64-array-index-of-*.js

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@JSTests/microbenchmarks/bigint64-array-index-of-small.js` at line 1, The test
file bigint64-array-index-of-small.js incorrectly uses the heavyweight marker
"//@ memoryHog!"; remove that marker (or replace it with a simple skip directive
if the test framework requires it) so this small 16-element BigInt64Array test
is not classified as a memory hog. Locate the "//@ memoryHog!" token in
bigint64-array-index-of-small.js and delete it (or change it to the appropriate
skip/comment directive), leaving the rest of the test (the array allocation and
any "let size = 16" logic) unchanged.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Incorrect memoryHog! classification for small array.

Despite the "big" in the filename, this test allocates only a 20-element array with 10k iterations. The memory footprint is negligible, making memoryHog! inappropriate. The "big" likely refers to loop-unrolling size rather than data size.

🔍 Verification: Check related loop-unrolling benchmarks

#!/bin/bash
# Description: Compare array sizes across loop-unrolling benchmarks

rg -n "Array\([0-9]+\)" JSTests/microbenchmarks/loop-unrolling-*.js
rg -n "memoryHog!" JSTests/microbenchmarks/loop-unrolling-*.js

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@JSTests/microbenchmarks/loop-unrolling-array-clone-big.js` at line 1, Remove
the incorrect "memoryHog!" tag from the test header in
JSTests/microbenchmarks/loop-unrolling-array-clone-big.js since the test only
allocates a 20-element array across 10k iterations (negligible memory); replace
it with either no tag or a clarifying comment that "big" refers to
loop-unrolling size rather than data size so the test is not misclassified by
memory-sensitive tooling.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

rg -nP --type=js -C2 '\bPromise\.reject\s*\(\s*\)(?!\s*\.catch\s*\()' JSTests/stress/promise-isPromise.js

Repository: oven-sh/WebKit

Length of output: 299

---

Attach a rejection handler to prevent unhandled-rejection warnings.

Line 20 creates a rejected promise with no .catch() handler, which can trigger unhandled rejection warnings in some test harness configurations, causing flaky test results.

Proposed fix

-shouldBe(Promise.isPromise(Promise.reject()), true);
+const rejectedPromise = Promise.reject();
+shouldBe(Promise.isPromise(rejectedPromise), true);
+rejectedPromise.catch(() => {});

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	shouldBe(Promise.isPromise(Promise.reject()), true);
	const rejectedPromise = Promise.reject();
	shouldBe(Promise.isPromise(rejectedPromise), true);
	rejectedPromise.catch(() => {});

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@JSTests/stress/promise-isPromise.js` at line 20, The rejected promise created
for the assertion (Promise.reject()) has no rejection handler and can trigger
unhandled-rejection warnings; update the call used with Promise.isPromise so the
rejected promise has a no-op rejection handler (e.g., attach .catch(() => {}) or
equivalent) while preserving the assertion, referencing the Promise.isPromise
and Promise.reject usage so the test still verifies isPromise(true) but avoids
unhandled rejections.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

In JavaScript, how does JSON.stringify treat undefined values in arrays versus objects, and does it preserve a distinction between undefined and null in array elements?

💡 Result:

In JavaScript, JSON.stringify treats undefined values differently in arrays versus objects. In arrays, undefined values are converted to null in the output JSON string. In objects, properties with undefined values are entirely omitted from the output. It does not preserve a distinction between undefined and null in array elements: both undefined and null become "null" in the JSON string. For example: JSON.stringify({ x: [10, undefined, function {}, Symbol("")] }); // '{"x":[10,null,null,null]}' JSON.stringify({ x: undefined, y: Object, z: Symbol("") }); // '{}' This behavior is specified in the ECMAScript standard: unrepresentable values like undefined in arrays become null, while in objects the property is excluded.

Citations:

• 1: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify
• 2: https://stackoverflow.com/questions/31284216/why-does-json-stringify-ignore-keys-whose-values-are-undefined
• 3: https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify
• 4: https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/JSON/stringify
• 5: https://mdn2.netlify.app/en-us/docs/web/javascript/reference/global_objects/json/stringify/

---

Strengthen shouldBe equality to avoid false-positive capture assertions

Line 9 uses JSON.stringify, which converts undefined to null in arrays. This can mask regressions in unmatched capture-group values, since regex capture groups return undefined when unmatched—if this were incorrectly changed to null, the comparison would still pass.

Proposed fix

 function shouldBe(actual, expected, message) {
-    if (JSON.stringify(actual) !== JSON.stringify(expected))
-        throw new Error(message + ": expected " + JSON.stringify(expected) + " but got " + JSON.stringify(actual));
+    function deepEqual(a, b) {
+        if (a === b)
+            return true;
+        if (!a || !b)
+            return a === b;
+        if (!Array.isArray(a) || !Array.isArray(b))
+            return false;
+        if (a.length !== b.length)
+            return false;
+        for (var i = 0; i < a.length; i++) {
+            if ((i in a) !== (i in b))
+                return false;
+            if (!deepEqual(a[i], b[i]))
+                return false;
+        }
+        return true;
+    }
+    if (!deepEqual(actual, expected))
+        throw new Error(message + ": expected " + JSON.stringify(expected) + " but got " + JSON.stringify(actual));
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@JSTests/stress/yarr-jit-paren-context-head-uaf.js` around lines 8 - 11, The
current shouldBe function uses JSON.stringify for comparison which collapses
undefined to null in arrays and can hide mismatches of regex capture groups;
update shouldBe to perform a strict deep equality check that preserves undefined
(e.g., use Node's assert.deepStrictEqual or implement a recursive deepEqual that
uses === for primitives and compares array lengths and elements including
undefined) and throw the same Error when they differ; modify the shouldBe
function to call that deep-equality routine instead of JSON.stringify so
unmatched capture groups are not treated as equal to null.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Narrow trap handling to avoid false-positive passes.

Line 102, Line 106, and Line 110 catch any exception; unexpected errors would still pass the test. Validate WebAssembly.RuntimeError (or rethrow unknown errors).

Proposed fix

+function expectOOBTrap(fn) {
+    try {
+        fn();
+        $vm.abort();
+    } catch (e) {
+        if (!(e instanceof WebAssembly.RuntimeError))
+            throw e;
+    }
+}
+
 // i32.load: 4 bytes -> last valid addr = PAGE-4, first invalid = PAGE-3
 inst.exports.scalarLoad(PAGE - 4);
-try { inst.exports.scalarLoad(PAGE - 3); $vm.abort(); } catch (e) {}
+expectOOBTrap(() => inst.exports.scalarLoad(PAGE - 3));
 
 // v128.load: 16 bytes -> last valid addr = PAGE-16, first invalid = PAGE-15
 inst.exports.simdLoad(PAGE - 16);
-try { inst.exports.simdLoad(PAGE - 15); $vm.abort(); } catch (e) {}
+expectOOBTrap(() => inst.exports.simdLoad(PAGE - 15));
 
 // v128.load64_lane: 8 bytes -> last valid addr = PAGE-8, first invalid = PAGE-7
 inst.exports.simdLane64Load(PAGE - 8);
-try { inst.exports.simdLane64Load(PAGE - 7); $vm.abort(); } catch (e) {}
+expectOOBTrap(() => inst.exports.simdLane64Load(PAGE - 7));

Also applies to: 106-107, 110-110

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@JSTests/wasm/stress/ipint-multimem-oob.js` around lines 102 - 103, The tests
currently catch all exceptions (e.g., in the try around
inst.exports.scalarLoad(PAGE - 3)) which can hide unexpected failures; update
each catch block (the ones guarding inst.exports.scalarLoad and similar OOB ops)
to rethrow any error that is not a WebAssembly.RuntimeError by replacing "catch
(e) { }" with "catch (e) { if (!(e instanceof WebAssembly.RuntimeError)) throw
e; }" so only expected WebAssembly runtime traps are swallowed and other errors
surface.

[coderabbitai]

🧹 Nitpick | 🔵 Trivial

Add explicit frame-length guard before indexed frame checks.

The current checks can throw a generic TypeError if the stack is shorter than expected, which obscures the real regression signal.

Suggested patch

     let captureIdx = frames.findIndex(f => f.startsWith("captureStack@"));
     assert.truthy(captureIdx >= 0, "Should find captureStack frame in: " + capturedStack);
+    assert.truthy(captureIdx + 2 < frames.length,
+        "Stack too short to validate wasm frame ordering: " + capturedStack);
     assert.truthy(frames[captureIdx + 1].includes("wasm-function"),
         "Frame after captureStack should be wasm callImport, got: " + frames[captureIdx + 1]);
     assert.truthy(frames[captureIdx + 2].includes("wasm-function"),
         "Frame after callImport should be wasm wasmEntry, got: " + frames[captureIdx + 2]);

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	// Verify the expected frame structure: captureStack -> callImport (wasm) -> wasmEntry (wasm)
	let captureIdx = frames.findIndex(f => f.startsWith("captureStack@"));
	assert.truthy(captureIdx >= 0, "Should find captureStack frame in: " + capturedStack);
	assert.truthy(frames[captureIdx + 1].includes("wasm-function"),
	"Frame after captureStack should be wasm callImport, got: " + frames[captureIdx + 1]);
	assert.truthy(frames[captureIdx + 2].includes("wasm-function"),
	"Frame after callImport should be wasm wasmEntry, got: " + frames[captureIdx + 2]);
	// Verify the expected frame structure: captureStack -> callImport (wasm) -> wasmEntry (wasm)
	let captureIdx = frames.findIndex(f => f.startsWith("captureStack@"));
	assert.truthy(captureIdx >= 0, "Should find captureStack frame in: " + capturedStack);
	assert.truthy(captureIdx + 2 < frames.length,
	"Stack too short to validate wasm frame ordering: " + capturedStack);
	assert.truthy(frames[captureIdx + 1].includes("wasm-function"),
	"Frame after captureStack should be wasm callImport, got: " + frames[captureIdx + 1]);
	assert.truthy(frames[captureIdx + 2].includes("wasm-function"),
	"Frame after callImport should be wasm wasmEntry, got: " + frames[captureIdx + 2]);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@JSTests/wasm/stress/jspi-stack-traces.js` around lines 65 - 71, The test
assumes at least three frames after finding captureStack but may index past the
array; add an explicit length guard on frames before accessing frames[captureIdx
+ 1] and frames[captureIdx + 2] (use frames.length and captureIdx) and assert
the stack is long enough with a clear message referencing capturedStack,
captureStack, and frames; only then perform the existing checks that the
subsequent frames include "wasm-function" to avoid a generic TypeError when the
stack is shorter than expected.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

Does WebAssembly memory64 proposal support shared memory with atomics?

💡 Result:

Yes, the WebAssembly memory64 proposal supports shared memory with atomics. The memory64 proposal extends the atomic memory instructions from the threads proposal to use 64-bit address operands when operating on a 64-bit memory. Specifically, atomic load/store, read-modify-write (e.g., i32.atomic.rmw, i64.atomic.rmw), compare-exchange, and wait/notify operations (memory.atomic.wait32/64, memory.atomic.notify) all support 64-bit indexing on memory64. Shared memory is defined in the separate threads proposal, which allows memories to be marked as shared, and memory64 builds on this by adapting the atomics for 64-bit addresses. There are no restrictions mentioned preventing shared memory64 with atomics; the instructions are compatible across both proposals.

Citations:

• 1: https://github.com/WebAssembly/threads/blob/main/proposals/threads/Overview.md
• 2: https://github.com/WebAssembly/memory64/blob/main/proposals/memory64/Overview.md
• 3: https://github.com/WebAssembly/spec/blob/main/proposals/memory64/Overview.md

---

🏁 Script executed:

fd -t f "memory64-atomics.js" --exec wc -l {} \;

Repository: oven-sh/WebKit

Length of output: 103

---

🏁 Script executed:

cat -n JSTests/wasm/stress/memory64-atomics.js | head -80

Repository: oven-sh/WebKit

Length of output: 5146

---

🏁 Script executed:

cat -n JSTests/wasm/stress/memory64-atomics.js | head -10

Repository: oven-sh/WebKit

Length of output: 585

---

🏁 Script executed:

cat -n JSTests/wasm/stress/memory64-atomics.js | sed -n '42,100p'

Repository: oven-sh/WebKit

Length of output: 4212

---

The file-level comment (lines 6-8) inaccurately describes what the test actually does.

The comment claims the test uses "memory64 (i64 addresses) with shared memory," but the atomic operations in the second block use memory32 shared (memory 1 1 shared). Since WebAssembly memory64 supports shared atomics, either:

1. Update the atomic block to use memory64 shared: (memory (export "memory") i64 1 1 shared) to match the file-level comment's intent, or
2. Fix the file-level comment to clarify that the file tests memory64 non-atomic operations separately from memory32 shared atomics.

The second block's line 42 comment correctly identifies "(memory32)," so updating lines 6-8 to match would resolve the confusion.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@JSTests/wasm/stress/memory64-atomics.js` around lines 42 - 49, The file-level
comment incorrectly states the test uses "memory64 (i64 addresses) with shared
memory" while the atomic block uses a memory32 shared declaration `(memory
(export "memory") 1 1 shared)`; either change that atomic block to a memory64
shared declaration `(memory (export "memory") i64 1 1 shared)` to match the top
comment, or update the file-level comment to state that the file tests memory64
non-atomic behavior separately and uses memory32 shared for the atomic block;
locate the module with `(memory (export "memory") 1 1 shared)` and adjust it or
edit the top-of-file comment accordingly.

[github-actions]

Preview Builds

Commit	Release	Date
e55776d2	autobuild-preview-pr-184-e55776d2	2026-04-18 12:08:25 UTC
3566460a	autobuild-preview-pr-184-3566460a	2026-04-18 09:50:53 UTC
43fee432	autobuild-preview-pr-184-43fee432	2026-04-17 16:42:45 UTC
fce1a0e8	autobuild-preview-pr-184-fce1a0e8	2026-04-17 06:24:15 UTC