Upgrade to upstream WebKit 2603e9eb41f0

[robobun]

Merge upstream WebKit c8b6308aaa69 into the Bun fork.

Previous sync: d81bcc3d833c (#263, squash-merged as c9ad5813fd23). 1113 upstream commits since then; 211 touch Source/JavaScriptCore / Source/WTF / Source/bmalloc. Because #263 was squash-merged, this branch first records d81bcc3d833c as an ancestor via -s ours (same pattern as 6812aa45de4f) so that git merge-base resolves correctly.

The merge commit's second parent is c8b6308aaa691fa0dd3f84bdcbf2d15a2f97b01e, upstream main as of the time this PR was opened.

Conflict resolutions

22 files conflicted; resolved as follows:

• DeferredWorkTimer.{h,cpp}: upstream's Ticket refactor (now ThreadSafeRefCountedAndCanMakeThreadSafeWeakPtr, addPendingWork returns WeakTicket, scheduleWorkSoon replaced by scheduleWorkSoonIfActive). Bun's onAddPendingWork/onScheduleWorkSoon/onCancelPendingWork hooks kept, updated to the new types (Ref<Ticket>&& / Ticket&).
• JSDateMath.{h,cpp}: upstream moved lastTimeZoneID to WTF::lastTimeZoneID() / WTF::timeZoneDidChange() behind USE(TIME_ZONE_CHANGE_NOTIFICATIONS). Bun's || USE(BUN_JSC_ADDITIONS) additions to the old PLATFORM(COCOA) guards are now obsolete; took upstream. Added || USE(BUN_JSC_ADDITIONS) to the USE_TIME_ZONE_CHANGE_NOTIFICATIONS define in PlatformUse.h and a no-op listenForTimeZoneChangeNotifications() stub in WTF/wtf/TimeZone.cpp for the Bun build (no platform notifier; Bun calls WTF::timeZoneDidChange() explicitly).
• JSMicrotask.cpp: upstream threaded a MicrotaskCallCache* through callMicrotask and the async-generator helpers, and extracted AsyncFunctionResume's body into asyncFunctionGeneratorBodyCall(). Bun's async-context save/restore blocks updated to pass microtaskCallCache and now wrap the new helper call.
• JSFinalizationRegistry.cpp / WasmStreamingCompiler.cpp: upstream's scheduleWorkSoonIfActive removes the hasPendingWork assertions. Bun's BUN_SKIP_FAILING_ASSERTIONS guards moved to the surviving asserts.
• PropertySlot.h: upstream added LastAttribute = DOMJITFunction. Kept Bun's Constructable = 1 << 17 and set LastAttribute = Constructable under USE(BUN_JSC_ADDITIONS).
• JSGlobalObject.h, MicrotaskQueueInlines.h, RunLoop.h, OptionsList.h, DeferredWorkTimer.h, BuiltinNames.{h,cpp}: kept both sides; upstream's additions placed adjacent to Bun's.
• RunLoopGeneric.cpp: upstream added releaseAssertIsCurrent(m_runLoop) in TimerBase. Under USE(BUN_EVENT_LOOP) the m_runLoop macro expands to the RunLoopGenericState optional, so the Bun branch asserts against m_runLoop->m_parent instead.
• JavaScriptCore/CMakeLists.txt: re-applied upstream's hunks (new JSCWebPreferenceOptions.h generator/target, Storage.json inspector domain, AsyncGeneratorPrototype.js/StringConstructor.js removed from builtins, DeferredWorkTimerInlines.h removed from private headers, *_HEADERS_DIR rename) on top of Bun's CMakeLists rather than taking upstream wholesale.
• ArrayPrototype.h, SparseArrayValueMap.h, JSDollarVM.h, WasmTable.h, WasmFormat.h, Interpreter.h, B3EliminateWasmGCAllocations.h: include-block-only conflicts; took upstream.

JSType.h did not change in this range; no src/jsc/JSType.rs update needed.

WebKit upgrade: upstream range d81bcc3d833c..c8b6308aaa69 (211 commits in JSC/WTF/bmalloc)

Notable changes

JIT / DFG / FTL / B3 / Air

• 6d70d346c664 Add LoadMegamorphicGetter IC
• 0d5d36b5f94e Add RegExpExecSticky DFG node
• 23903f1a1cc7 Add AtomString Array loop in DFG / FTL
• 082efc20347d Handle String#trim / trimStart / trimEnd in DFG / FTL
• eeb2440ba085 Inline StringSlice rope construction in FTL
• 752e7e8b0d05 Convert HasOwnProperty on current for-in key to EnumeratorHasOwnProperty
• 7f538702bc4e Prove resolved values non-thenable for NewResolvedPromise in DFG constant folding
• 338e02c8838a Fix DFG strength reduction folding compiler-thread RegExp failure into a definite no-match
• d801f1e36011 / 674917cb5f4d / 71208eb12b5e Shrink Air::Arg to 16 bytes, Air::Inst to 64 bytes
• 0f2107b6d205 Remove Air::lowerMacros; 5d5a2e3a036f single-pass Air::simplifyCFG
• ebe71899e170 Adjust JIT tier-up thresholds for Macs with fewer P-cores

GC / Heap

• 5ecce0f050d2 / 6fddaa00b614 Manually pipeline memory fetching for GC marking (SlotVisitor prefetch)
• f0df03efe38c Tweak number of GC threads on Apple platforms
• 904ba5171187 Strong<T> is now pointer-sized
• b80bcf43bdce SparseArrayValueMap 33% more compact using HashSet

Runtime / Promises / Async

• d11c8c7ba675 / 3ac446bb73b3 Polymorphic MicrotaskCallCache for microtask calls, threaded through more functions
• 5f65bd95a4b6 Cooperative driving of async generators
• 74cc52330394 Use JSSlimPromiseReaction for JSAsyncGenerator queue
• 793fd5461d93 async-generator fast consume inserts ExitOK
• 707b16ac07ea PromiseResolveThenableJob rejects when SpeciesConstructor throws
• 8490d02c5dcc AsyncFromSyncIterator closes correctly on rejected value promise
• 8e15aeeee3bc Improve exception unwinding performance
• 3bd19f0a328e Move object structured-cloning code into JSC

Strings / RegExp / YARR

• 4e93b58dfd8e Array#join writes rope elements directly into result buffer
• 485bcf1b176a Fast path for Array#concat with multiple arguments
• bef2808f4db2 Parse replacement template once in String#replace (global + $ substitutions)
• 5031c9001ee2 Implement String.raw in C++
• 7a764d7acc54 Yarr collects BM info for fixed-count terms; e13280f56c44 rearrange YarrJIT registers for regT3
• 630d6be8962a Fix YARR EOL string-list optimization with multiline flag

WebAssembly

• c7bfc7c0ca52 Add B3::eliminateWasmGCAllocations phase; a2bb3b59f1cc fold WasmGC object comparisons
• 1152f3717e9b Implement Table64 JS API
• 7f065ab4abdb Fix streaming instantiation using result promise as import object when imports omitted
• 228685d7d2a3 Names in Error stacktrace for instantiateStreaming modules
• bccb52eace5b / f854abcc8468 BBQ strength-reduce signed div/rem by negative pow2; mask before shr
• fb30bac88bb4 Wasm debugger: replace polling STW participation with VMBlockingScope

Temporal / Intl

• 23eb4f85f358 Enable Temporal object by default
• cfda643c04c0 / 2fb282a82538 / 170ee738c6f1 / bdd3b71e35c2 / d3c7fd25598a / a0433cfeb9ab / 1482a7ad4add / 75d9be0204db / f9f65c7ff4f6 Multiple Temporal spec-alignment & calendar fixes (ZonedDateTime, PlainDateTime, PlainYearMonth, PlainMonthDay, non-ISO calendars, Duration rounding)
• 6ea58a42a909 Add useIntlEraMonthcode option, narrow AvailableCalendars
• 824d2b29e233 Use modern unit/ skeleton in Intl.NumberFormat
• cde1f2154e51 Use IntlCache for Temporal pattern generation in Intl.DateTimeFormat

Parser / Bytecode / LLInt

• d981384b263d Add TokNumberInt32 to LiteralParser to remove number-conversion overhead
• 1994bc0cc3e2 Skip unreachable implicit return for arrow function expression bodies
• c0e48d007a10 LLInt records IterationMode::Generic in op_iterator_next / op_async_iterator_next
• 69ab6c6330aa Fix CLoop with loadh / storeh

WTF / bmalloc

• 3aa0615a5649 Fix WTF::divideRoundedUp overflow near type max
• 39dc095e8f0e Fix calculateBase64EncodedSize() truncation for >4 GB inputs
• b420bd341074 Fix pairIntHash bit extraction degrading hash distribution
• 6cccd5ef64ee / 82b692fc69fc / dce31d0f206f libpas: fix OoB paths in MAR code, segregated-heap race, zeroed-alloc bug

Bun-relevant API changes

• DeferredWorkTimer Ticket refactor (15c117a5444a): TicketData is now ThreadSafeRefCountedAndCanMakeThreadSafeWeakPtr. addPendingWork() returns a WeakTicket (ThreadSafeWeakPtr<TicketData>) instead of a raw Ticket. scheduleWorkSoon(Ticket, Task&&) is replaced by scheduleWorkSoonIfActive(WeakTicket&&, Task&&) / mustScheduleWorkSoonIfActive(...), and cancelPendingWork() now takes a WeakTicket&&. Callers that held a raw Ticket must be updated to hold WeakTicket and use the *IfActive variants.
• Time-zone change detection moved to WTF (65d36770c7a6, a01ee718ca4d): JSDateMath now checks WTF::lastTimeZoneID() / WTF::timeZoneDidChange() guarded by USE(TIME_ZONE_CHANGE_NOTIFICATIONS). Ports without notifications re-read the host zone on each cache reset. Embedders that previously called DateCache::timeZoneChanged() directly should route through the new WTF hooks.
• Microtask call cache (d11c8c7ba675, 3ac446bb73b3, 5f65bd95a4b6): callMicrotask() in JSMicrotask now takes an additional MicrotaskCallCache* parameter. AsyncFunctionResume's body was factored out into asyncFunctionGeneratorBodyCall() which also threads the cache. Any Bun code calling callMicrotask / resuming async functions directly needs the extra argument.
• PropertyAttribute::LastAttribute sentinel (b80bcf43bdce): the PropertyAttribute enum gained a LastAttribute sentinel used by the new compact SparseArrayValueMap encoding. static_asserts against attribute bit-width may need updating.
• New generated header JSCWebPreferenceOptions.h (3af9d4073d75): JSC feature flags are now driven by UnifiedWebPreferences.yaml; the build emits a new JSCWebPreferenceOptions.h that must be on the include path / in generated-sources lists.

[claude]

Both prior findings look fixed in a67975c — the TimeZone.cpp stub guard now keys on OS(DARWIN), and AsyncGeneratorDriverResume has the async-context wrap/unwrap matching its siblings. No new issues surfaced on this pass, but a 211-commit upstream merge with 22 hand-resolved conflicts across the JIT tiers, GC, DeferredWorkTimer, and the async/microtask runtime is well beyond what I'd sign off on without a human look.

What was reviewed:

• Re-checked the TimeZone.cpp / PlatformUse.h / PlatformJSCOnly.cmake interaction — OS(DARWIN) now matches the CMake APPLE gate, so the macOS JSCOnly build gets exactly one listenForTimeZoneChangeNotifications definition.
• Re-checked JSMicrotask.cpp — the AsyncGeneratorDriverResume enqueue sites and dispatch case now carry m_asyncContextData under USE(BUN_JSC_ADDITIONS) like the other resume-body cases.
• Scanned the remaining conflict-resolution files (DeferredWorkTimer, PropertySlot.h LastAttribute, RunLoopGeneric.cpp, CMakeLists) and the Bun-hook call sites for the new WeakTicket / scheduleWorkSoonIfActive API — nothing further stood out.

Extended reasoning...

Overview

This PR merges upstream WebKit d81bcc3d833c..c8b6308aaa69 (211 commits touching JSC/WTF/bmalloc, ~300 files in the diff) into the Bun fork. It is not a mechanical merge: 22 files conflicted and were hand-resolved, several of them at Bun's integration seams — DeferredWorkTimer (Ticket → ThreadSafeWeakPtr refactor with Bun's onAddPendingWork/onScheduleWorkSoon/onCancelPendingWork hooks re-plumbed), JSMicrotask.cpp (new MicrotaskCallCache* threading + asyncFunctionGeneratorBodyCall extraction interleaved with Bun's async-context save/restore), JSDateMath/PlatformUse.h/TimeZone.cpp (time-zone-change detection moved to WTF), PropertySlot.h (LastAttribute sentinel vs. Bun's Constructable bit), RunLoopGeneric.cpp under USE(BUN_EVENT_LOOP), and the JSC CMakeLists.txt. Upstream also enables Temporal by default, adds a LoadMegamorphicGetter IC, reworks Air arg/inst layout, and introduces the cooperative async-generator driver that my earlier finding was about.

Security risks

The upstream range includes JIT codegen changes (new IC kind, Air layout shrink, B3 WasmGC allocation elimination, YARR register reshuffle), GC marking pipelining, and libpas fixes. None of the Bun-side conflict resolutions introduce new attack surface on their own, but mis-merged JIT/GC code is exactly the class of change where a subtle error becomes a memory-safety bug. The two issues found on the first pass were a build break and an async-context correctness regression — not security bugs — and both are now addressed. I did not identify any injection, auth, or data-exposure surface; the risk here is entirely in engine correctness/memory-safety, which is inherent to the upstream content rather than the merge mechanics.

Level of scrutiny

High. This is the core JS engine for a production runtime, the diff is ~700 KB, and the interesting parts are precisely the 22 hand-resolved conflicts plus any upstream additions that silently bypass Bun's USE(BUN_JSC_ADDITIONS) hooks (the AsyncGeneratorDriverResume case was one such — it caused no textual conflict). That combination puts it firmly outside "approve without a human look." The preview autobuilds passing on both post-fix commits is a good signal that the platform-guard fix took, but CI can't validate the semantics of the conflict resolutions.

Other factors

On the previous run I flagged two issues; robobun fixed both in a67975c412, resolved the threads, and added Bun-side AsyncLocalStorage + for await coverage. This run's bug-hunting pass over the updated branch found nothing new, and I spot-checked the fixes against the described root causes — they match the pattern used by the sibling code. Given the scope, the right outcome is a human review of the conflict-resolution hunks (particularly DeferredWorkTimer.{h,cpp}, JSMicrotask.cpp, and the CMake re-application) rather than an automated approval.

[claude]

🔴 The a67975c fix for the AsyncGeneratorDriverResume async-context regression is incomplete: wrapWithCurrent at JSMicrotask.cpp:491 runs at dequeue time inside the producer's AsyncContextSwapScope (from the AsyncGeneratorYieldAwaited/BodyCallNormal dispatch cases), so it captures the producer's context — while the generator-queue enqueue at line 636 still stores the driver raw. When the generator is already Executing when for await starts (e.g. a prior .next() under context X, then for await under context Y), the consumer's loop body resumes under X instead of Y. Fix: wrap the driver at line 636 (which runs under the consumer's context, like the completed-state branch at 628-632 already does) and use the dequeued target's captured context in asyncGeneratorCompleteStep instead of wrapWithCurrent.

Extended reasoning...

What the bug is

Commit a67975c addressed the earlier review finding that InternalMicrotask::AsyncGeneratorDriverResume had no Bun async-context handling. It added the standard unwrap+swap block to the dispatch case (JSMicrotask.cpp:1998-2005), wrapped the driver in the completed-state fast path of enqueueAsyncGeneratorDriver (line 628-632), and — for the general case — called AsyncContextSwapScope::wrapWithCurrent in asyncGeneratorCompleteStep at line 491, i.e. at the point where a driver is dequeued from the generator's queue and an AsyncGeneratorDriverResume microtask is scheduled.

The problem is that line 491 executes inside the producer's async-context swap scope, not the consumer's. asyncGeneratorCompleteStep is reached synchronously from asyncGeneratorYield / asyncGeneratorBodyCall, which are invoked from the AsyncGeneratorYieldAwaited and AsyncGeneratorBodyCallNormal dispatch cases (lines 1954-1973). Each of those cases constructs an AsyncContextSwapScope from the context the producer captured on its own earlier await (via resolveWithInternalMicrotaskForAsyncAwait at lines 716/721). So wrapWithCurrent at line 491 reads back whatever context the producer was running under — not the context the consumer was in when it enqueued the driver.

Meanwhile, the actual enqueue site — iterator->enqueue(vm, jsUndefined(), NormalMode, driver) at line 636 — runs synchronously from op_async_iterator_next under the consumer's context, but stores the driver raw with no capture.

Why the common case still works

When the generator is idle (Init / SuspendedYield) at the time for await calls next, line 639 is true and asyncGeneratorResume runs the producer synchronously under the consumer's context. Every subsequent producer await captures that same context, so when line 491 later runs it reads back the consumer's context by coincidence. This is why the new AsyncLocalStorage.test.ts cases added alongside a67975c pass.

The failing case

When the generator is already Executing/Awaiting at the time for await starts, none of that propagation happens:

• asyncIteratorOpenTryFastImpl (CommonSlowPaths.cpp:959-996) checks only JSAsyncGeneratorType + primordial @@asyncIterator/.next + species watchpoint; it does not check generator state, so an already-executing generator still gets the FastAsyncGenerator sentinel.
• enqueueAsyncGeneratorDriver: state is not Completed (skip 626-633) and not Init/SuspendedYield (line 639 false), so line 636 enqueues the raw driver under the consumer's context Y and returns without resuming.
• asyncFunctionArrangeAwaitResume (line 1632) sees the fast sentinel and returns early — the consumer's own await-time ForAsyncAwait capture, which pre-merge would have snapshotted Y, is bypassed.
• Later the producer's pending await resolves → AsyncGeneratorBodyCallNormal/YieldAwaited restores the producer's context X → the generator runs to a yield or completion → asyncGeneratorCompleteStep dequeues the driver → line 491 wrapWithCurrent captures X → AsyncGeneratorDriverResume dispatch (1998-2005) restores X → the consumer's loop body runs under X instead of Y.

Step-by-step proof

async function* g() { await sleep(10); yield 1; yield 2; }
const it = g();
als.run(X, () => { it.next(); });                 // (1)
als.run(Y, async () => {
  for await (const v of it)                       // (2)
    console.log(als.getStore());                  // prints X, expected Y
});

1. Manual .next() under X → asyncGeneratorResume runs the producer synchronously under X; producer hits await sleep(10) → resolveWithInternalMicrotaskForAsyncAwait captures X; state = Executing/Await; queue = [JSPromise-for-manual-next].
2. for await under Y → op_async_iterator_open stamps the fast sentinel (no state check) → op_async_iterator_next → enqueueAsyncGeneratorDriver: state is Await, so line 636 enqueues the raw driver; line 639 false, no resume. Consumer suspends; its own await-time capture is skipped by the sentinel early-return.
3. sleep resolves → AsyncGeneratorBodyCallNormal restores X, producer resumes and reaches yield 1 → AsyncGeneratorYieldAwaited (also captured X) → asyncGeneratorYield → asyncGeneratorCompleteStep dequeues the manual-next JSPromise and resolves it. Queue still has [driver]; asyncGeneratorYield line 671 sees the queue non-empty and re-enters the producer without suspending. Producer reaches yield 2 → asyncGeneratorCompleteStep dequeues driver → line 491 wrapWithCurrent reads m_asyncContextData, which is X (set by the enclosing swap scope) → schedules AsyncGeneratorDriverResume(driver-wrapped-with-X).
4. Dispatch case 1998-2005 unwraps X, swaps it in, and resumes the consumer → als.getStore() returns X.

Pre-merge, step (2) would have called real .next() returning a JSPromise, and the consumer's own implicit await would have gone through resolveWithInternalMicrotaskForAsyncAwait capturing Y at .then()-time (Node.js semantics). Post-merge the fast path skips that entirely; the only capture point is line 491, under the producer's scope.

The same failure applies to two concurrent for await loops from different contexts on the same generator: the second loop's driver is enqueued while state=Executing (from the first loop) and later dequeued under the first loop's propagated context.

Fix

The original review comment recommended capturing "at the enqueue sites". a67975c did this correctly for the completed-state branch (line 628-632, which runs under the consumer's context) but placed the general capture at the wrong end of the queue. To fix:

• At line 636, wrap the driver with the current async context (e.g. via InternalFieldTuple, matching line 629). This is the point that runs under the consumer's context. JSAsyncGenerator::enqueue/dequeue may need to accept a JSValue target under USE(BUN_JSC_ADDITIONS).
• In asyncGeneratorCompleteStep, when the dequeued target is a driver, pass it through as-is (it is already wrapped) instead of calling wrapWithCurrent on the ambient context.