Bun/upgrade to dbdca7545d

[sosukesuzuki]

Upgrade to upstream WebKit dbdca75

Merges upstream WebKit dbdca7545d (2026-10-05): 1020 commits since 7b485a76e9 (#725), 188 of them in Source/JavaScriptCore, Source/WTF or Source/bmalloc.

Please land this as a merge commit, not a squash. #725 was squashed, so git's merge base with upstream stayed at ccdcb8a026. This merge was computed against 7b485a76e9 and records upstream as a parent; a squash would lose that again.

Three commits:

1. 049e2899097 removes the fork's for-of / array destructuring change (the first and third commits of [JSC] for-of / array destructuring without an Array Iterator object, and one RegExpObject per /x/.test(s) literal site #630). Upstream landed the same change as 321765@main and built the Baseline and LLInt inline paths, String iteration and a DFG fix on it. With the fork's copy gone the merge takes upstream's as it is. The RegExp literal part of [JSC] for-of / array destructuring without an Array Iterator object, and one RegExpObject per /x/.test(s) literal site #630 stays. This commit does not build by itself.
2. 661e26ef130 is the merge. Its message lists every conflict; the same list is below.
3. 05fef3340d7 brings back what the fork had tied to op_iterator_close_check and that still applies: it is not counted in CodeBlock::bytecodeCost(), the bytecode optimizer leaves its operands alone, the two RELEASE_ASSERTs for a sentinel cell, cachedTypesFormatRevision 13, and the test run lines.

The merge

1020 upstream commits since 7b485a7 (the previous upgrade, #725), 188 of them
in Source/JavaScriptCore, Source/WTF or Source/bmalloc.

#725 landed as a squash, so git's merge base with upstream was still
ccdcb8a. This merge was computed against 7b485a7 (a temporary
git replace --graft gave 7465044 its upstream parent). It records
upstream/main as a parent, so the next upgrade finds its base by itself as long
as this lands as a merge commit and not as a squash.

Conflicts, and what was done about them:

Heap / Collector (c2fa192 and the eight commits after it move the
collection cycle out of Heap into a new Collector class):

• Heap.cpp, Heap.h: upstream's layout, with the fork's changes carried over.
  The auxiliary block evacuation, setInitialAllocationBudget(),
  releaseUnusedSharedBaselineCode() (now called from pruneDeadReferences()),
  the decoder string table hooks, the allocation counters and the aging stamps
  stay in Heap. The stamps that runBeginPhase() takes moved with it to
  Collector::runBeginPhase(). Heap::isIdleCollection() is out of line, since the
  current request is the Collector's.
• GC rate limiting stays reverted (642e225): it is taken out of upstream's
  new Heap::recordCollectionTime() too.
• GCRequest::didFinishEndPhase stays. Upstream removed it as unused
  (a516249); Bun sets it (JSC__VM__collectAsyncIdle). Collector::runEndPhase()
  runs it where Heap::runEndPhase() did.

Source positions (93ebfac, c59d70e):

• SourceProvider keeps the fork's encoded line start tables and its virtual
  lineColumnInTextForOffset(). That function now goes through upstream's
  LineStartTable::zeroBasedLineColumnForOffset(), which builds the table with
  withSourceConcurrently() and is safe off the main thread.
• ExpressionInfo has both caches: upstream's decoded entries (under the unlinked
  code block's lock) and the fork's line/column map. decodeEntryForInstPC() is
  public, for the caller of expressionInfoIfDecoded() that can neither lock nor
  allocate.
• BuiltinsSourceProvider keeps lineStartAfterTerminator(), which upstream
  dropped from SourceCharacters.h.

ErrorInstance (696c406, lazy Error.captureStackTrace): upstream's captured
stack trace next to the fork's onComputeErrorInfo hooks. m_hasErrorInfo replaces
the empty-string placeholder, and setStackFrames() clears it with the string.
m_stackString is written under the cell lock in the new paths as well, because
the fork reads it from estimatedSize() during marking.

Microtasks (53d4af9): runInternalMicrotask() takes its arguments by value.
With USE(BUN_JSC_ADDITIONS) there are four of them (maxMicrotaskArguments is 4),
and the four-argument JSGlobalObject::queueMicrotask() gets the same fast path.

JSON (f62059d and the JSONCache commits): JSONAtomStringCache is gone. The
fork's out-of-memory handling for long strings is now
JSONCache::tryMakeJSString() / tryMakeLongJSString(), and the new inline string
path of the parser checks for null. JSONCacheInlines.h is a private header (Bun
includes it).

JSBigInt (b071cfa, 13a1f29): the fork's division (Burnikel-Ziegler with
interrupt checks, Barrett) is kept as it is. Upstream's Burnikel-Ziegler, which
has lower thresholds and does not allocate at the leaves, is not taken; its three
helpers that nothing else used are left out.

WTF / libpas:

• AvailableMemory: upstream's structure (7cc8fd9), with the cgroup limit
  (uv_get_constrained_memory) and the FreeBSD branch. The statm parsing fix is
  carried to MemoryFootprintGeneric.cpp, where LinuxMemory moved.
• pas_compact_heap_reservation.c (5b0cfbc, two allocation fronts): Windows
  commits on demand for the top front too, and initializes both committed marks.
• URLParser: the fork's scheme scan, with upstream's shrink(0).
• AssemblerBuffer: both caps apply (upstream's option is off by default).

Fork code adjusted to upstream API changes: typed C strings in ffi/ (UTF8CString),
ASCIILiteral messages for DFG_CRASH, Collector::suspendCompilerThreads(),
JSModuleLoader::drainSynchronousModuleQueue().

Not taken, for a follow-up

• Upstream's Burnikel-Ziegler division (b071cfab287, 13a1f291693) has lower thresholds than the fork's and does not allocate at the leaves. The fork keeps its own division, which also has the interrupt checks and Barrett.
• Options::useUnboxedFastArrayIteration is gone with the fork's iterator change. Upstream has no option for it.

Verification

• jsc and Bun build against this tree (debug + ASAN, Linux x64, clang 23.1.2). No other platform was built here.
• About 1,330 JSTests/stress files in the areas the merge touched (iteration, JSON, BigInt, errors and stack traces, promises and async, modules, generators, GC), run with the debug jsc: all pass. 55 are skipped by their own directives. Eight needed their own options, a larger stack or more time than my ad-hoc runner gave them, and pass when run that way. The full JSC test run of CI has not been run.
• Bun's suites for the same areas pass on a build against this tree (see the Bun PR).

[claude]

Findings marked 🟡 are optional suggestions and need no follow-up push.

Additional findings (outside the current diff — GitHub can't attach inline comments there):

• 🔴 Source/JavaScriptCore/runtime/JSArray.cpp:1109 — Anyone who calls Array.prototype.splice on an array made immutable by JSObject::makePropertiesImmutable now mutates it in place or crashes, instead of getting the base branch's TypeError. fastSplice (JSArray.cpp:1063) never checks tryMakeWritable or hasImmutableProperties: at JSArray.cpp:1101-1107 it ignores the false that shiftCountWithAnyIndexingType / unshiftCountWithAnyIndexingType return for such an array and then memcpy's the items into the copy-on-write butterfly, and at JSArray.cpp:1109 ensureWritable trips the RELEASE_ASSERT in convertFromCopyOnWrite. Fix: fastSplice must return false whenever the array's elements cannot be made writable, e.g. if (!tryMakeWritable(vm)) return false; before any mutation.

  Why this was flagged

  The fork makes an Int32/Double/Contiguous JSArray immutable by keeping its elements in copy-on-write storage (JSObject.cpp:3108-3135, Options::useCopyOnWriteArraysForImmutableProperties); its indexingType() still reads ArrayWithInt32 etc. because the CopyOnWrite bit is masked (JSCell.h:157), and tryMakeWritable returns false for it (JSObjectInlines.h:1651-1659). Upstream's new JSArray::fastSplice, reached from arrayProtoFuncSplice (ArrayPrototype.cpp:1250-1256) and from arraySpliceImpl (DFGOperations.cpp:1597), was merged without that check. For a.splice(1, 0, 9) unshiftCountWithAnyIndexingType returns false at JSArray.cpp:1941-1942; ASSERT_UNUSED at JSArray.cpp:1106 is a no-op in release, so the memcpy at JSArray.cpp:1122 writes 9 over element 1 of the immutable butterfly and splice returns normally. On the base branch splice went through shift/unshift and putByIndexInline, where JSArray::put (JSArray.cpp:317) and the refused deletes threw TypeError, which JSTests/stress/immutable-properties-array-storage.js:99-102 asserts for a => a.splice(10, 5).

  Verification: New JSArray::fastSplice (Source/JavaScriptCore/runtime/JSArray.cpp:1063-1128) gates only on indexingType() (JSCell.h:157 masks the CopyOnWrite bit, so an immutable CoW array still reads ArrayWithInt32/Double/Contiguous), length, holes and item kinds; it never calls tryMakeWritable or checks hasImmutableProperties.

• 🟡 Source/JavaScriptCore/runtime/ArrayPrototypeInlines.h:155 — Callers of push(), splice() with no arguments, or pop()/shift() on an empty array no longer get a TypeError when the array was made immutable with copy-on-write storage; they silently succeed. The new early return at ArrayPrototypeInlines.h:154-155 assumes only ArrayStorage can hold a read-only length, but the fork's JSArray::setLength also refuses an unchanged length for CopyOnWrite arrays whose structure hasImmutableProperties (JSArray.cpp:1352-1356). Fix: keep routing to JSArray::setLength whenever the length is read-only, e.g. only take the early return when !array->structure()->hasImmutableProperties() as well, so every setLength caller in ArrayPrototype.cpp (lines 558, 743, 1192, 1271, 609, 1301) still throws for immutable arrays.

  Why this was flagged

  An array made immutable via JSObject::makePropertiesImmutable keeps Int32/Double/Contiguous copy-on-write storage (JSObject.cpp:3108-3121), so hasAnyArrayStorage(array->indexingType()) is false. arrayProtoFuncPush with zero arguments reaches setLength(globalObject, vm, thisObj, length) at ArrayPrototype.cpp:609 with newLength == length; arrayProtoFuncSplice with no arguments does so at ArrayPrototype.cpp:1192; pop and shift on a length-0 array at ArrayPrototype.cpp:558 and 743. On the base branch this always called JSArray::setLength, whose CopyOnWriteArrayWith* case throws ReadonlyPropertyWriteError when structure()->hasImmutableProperties() (JSArray.cpp:1355-1356). After the merge the comparison at ArrayPrototypeInlines.h:154 returns before that check, so the call completes without an exception. Frozen arrays via Object.freeze are unaffected because preventExtensions gives them ArrayStorage; only the fork's immutable arrays lose the error.

  Verification: The new early return in ArrayPrototypeInlines.h:152-155 returns when !hasAnyArrayStorage(array->indexingType()) && array->length() == value. The base called setLength unconditionally. JSArray::setLength (JSArray.cpp:1352-1356) throws ReadonlyPropertyWriteError for CopyOnWriteArrayWith* when structure()->hasImmutableProperties() before the newLength == publicLength() check. Existing tests only cover push(9)/splice(0,1), which change length.

• 🟡 Source/WebCore/Modules/cookie-store/CookieStore.cpp:396 — Sites on Cocoa that call cookieStore.set() with a non-ASCII name or value now send mojibake to their server in the Cookie request header. CookieStore.cpp:395-396 rewrites cookie.name and cookie.value through cookieStringForStorage, which on Cocoa (CookieCocoa.mm:226-236) turns the UTF-8 bytes into a Latin-1 String before createNSHTTPCookie; CFNetwork then UTF-8-encodes that string on the wire, so the bytes are double-encoded. The diff's own rebaseline records this: the subtest "HTTP headers agreed with CookieStore on encoding non-ASCII cookies" flips PASS to FAIL with the server receiving "ðª=ðµ" for '🍪=🔵'. Fix: cookies written by cookieStore.set must reach the server as the UTF-8 bytes of the script string (as on the base branch) while still matching names written through document.cookie.

  Why this was flagged

  A page on macOS/iOS runs cookieStore.set('🍪', '🔵') and then fetches a same-origin resource with credentials. CookieStore::set at Source/WebCore/Modules/cookie-store/CookieStore.cpp:395-396 passes cookie.name and cookie.value through CookieUtil::cookieStringForStorage before the Cookie reaches CookieStorageSession::setCookieFromDOM (CookieStorageSessionCocoa.mm:408) and Cookie::createNSHTTPCookie (CookieCocoa.mm:150,159). On Cocoa cookieStringForStorage (CookieCocoa.mm:226-236) returns String(byteCast(scriptValue.utf8().span())). CFNetwork serializes the Cookie request header by UTF-8-encoding those NSStrings, so the server receives C3 B0 C2 9F C2 8D C2 AA instead of F0 9F 8D AA. The diff records exactly this in LayoutTests/imported/w3c/web-platform-tests/cookiestore/change_eventhandler_for_http_cookie_and_set_cookie_headers.https.window-expected.txt:7, where the subtest 'HTTP headers agreed with CookieStore on encoding non-ASCII cookies' goes from PASS to FAIL with 'HTTP cookie jar contains only cookie we set expected "🍪=🔵" but got "ðª=ðµ"'. On the base branch this subtest passed, so the server received the correct UTF-8 bytes.

  Verification: Source/WebCore/Modules/cookie-store/CookieStore.cpp:395-396 (new) rewrites cookie.name and cookie.value through cookieStringForStorage before the Cookie reaches storage. On Cocoa, CookieCocoa.mm:226-236 returns String(byteCast(scriptValue.utf8().span())), and CookieCocoa.mm:150/159 put that string into NSHTTPCookieName/NSHTTPCookieValue. The rebaseline flips the non-ASCII subtest from PASS to FAIL with "ðª=ðµ".

[github-actions]

Preview build of 5dbf444: autobuild-preview-pr-773-5dbf444e

[claude]

Findings marked 🟡 are optional suggestions and need no follow-up push.

Additional findings (outside the current diff — GitHub can't attach inline comments there):

• 🔴 Source/JavaScriptCore/runtime/ErrorInstance.cpp:596 — Reading err.stack on an error whose properties were made immutable after Error.captureStackTrace(err) now hands JS the internal CustomGetterSetter cell and loses the captured frames, where the base returned the stack string. materializeCapturedStackPropertyIfSaved moves the frames out and then calls putDirect at ErrorInstance.cpp:596 without the AllowLazyMaterializationOfImmutableProperties scope, so JSObjectInlines.h:510-512 refuses the store and the placeholder accessor stays. Fix: perform that putDirect under AllowLazyMaterializationOfImmutableProperties like ErrorInstance.cpp:517 and :538, and make errorInstanceMaterializingStackGetter never return the accessor cell (format and return the string when the store is refused).

  Why this was flagged

  Trigger: Error.captureStackTrace(err) on an extensible ErrorInstance installs a CustomValue placeholder for "stack" and saves the frames in m_capturedStackTrace (ErrorInstance.cpp:562-577); the object is then made immutable with JSObject::makePropertiesImmutable, and err.stack is read. materializeCapturedStackPropertyIfSaved moves m_capturedStackTrace and m_stackString out (ErrorInstance.cpp:587-590), formats the string, then calls putDirect at ErrorInstance.cpp:596 with no AllowLazyMaterializationOfImmutableProperties scope. putDirectInternal returns ReadonlyPropertyChangeError at JSObjectInlines.h:510-512 because structure->hasImmutableProperties(), so nothing is stored and the return value is ignored. The frames are now gone and the CustomValue placeholder remains, so errorInstanceMaterializingStackGetter (ErrorInstance.cpp:42-48) finds m_capturedStackTrace null and returns getDirect(vm, stack), i.e. the CustomGetterSetter cell itself, to JavaScript. On the base branch captureStackTrace stored the formatted string directly, so err.stack was a string regardless of later immutability.

  Verification: materializeCapturedStackPropertyIfSaved (ErrorInstance.cpp:579-598) moves m_capturedStackTrace and m_stackString out into locals and then calls plain putDirect at line 596 with no AllowLazyMaterializationOfImmutableProperties scope, unlike the sibling puts at lines 497, 517 and 538; JSObjectInlines.h:510-512 returns ReadonlyPropertyChangeError, the return value is ignored, and the captured trace is gone for good.

• 🟡 Source/JavaScriptCore/runtime/LiteralParser.cpp:931 — nit (Bun-only): callers of streamingJSONParse now get a stale charactersConsumed on the error path, pointing inside a value that was already appended to results. The new fast-path lexer helpers (nextAfterValue at LiteralParser.cpp:907, also nextString, nextNumber, consumeColon) advance m_ptr without updating m_positionAfterLastToken, which only lex() sets at LiteralParser.cpp:764. tryStreamingParse reads it at LiteralParser.cpp:2348 right after a value whose next character is ',', '}' or ']'. Fix: record m_positionAfterLastToken in every helper that consumes a token under USE(BUN_JSC_ADDITIONS), or fall back to next() there, so the position always follows the last consumed token.

  Why this was flagged

  Input to Bun's streamingJSONParse such as {"a":1},\n{"b":2} (a top-level value directly followed by ',', '}' or ']'). parseRecursively ends the object with m_lexer.nextAfterValue() at LiteralParser.cpp:1916; nextAfterValue sees ',' and takes the fast path at LiteralParser.cpp:917-931, which only bumps m_ptr and sets m_currentToken.type. m_positionAfterLastToken is only assigned inside lex() at LiteralParser.cpp:764, so it still holds the position from the last full lex() call, which for this object is just after '{'. tryStreamingParse at LiteralParser.cpp:2348-2363 then sets lastGoodPosition to that stale offset and returns Status::Error with charactersConsumed inside the value even though the value was appended to results at LiteralParser.cpp:2347. On the base branch every token went through lex(), so lastGoodPosition was the offset right after '}'. jsc.cpp:2389 exposes this as charactersConsumed. Only the position differs; the status is Error on both branches.

  Verification: Triggered only in a USE(BUN_JSC_ADDITIONS) build when a streamingJSONParse top-level value is directly followed by ',', '}' or ']'. m_positionAfterLastToken = m_ptr; is assigned only in Lexer::lex() (LiteralParser.cpp:764); nextAfterValue() (907-933) does ++m_ptr without touching it. tryStreamingParse (2347-2348) then returns Error with a stale charactersConsumed pointing inside a value already appended to results.