Upgrade to upstream WebKit 01aaa3e0be0c

[robobun]

Merges WebKit/WebKit@01aaa3e0be0c (2026-07-25) into the fork. 538 upstream commits since the previous sync point (2603e9eb41f0); 117 touch Source/JavaScriptCore, Source/WTF or Source/bmalloc.

Conflict resolution

Nine files conflicted. Seven were include-block noise from the squash-sync ancestor (the conflict region carried the pre-<JavaScriptCore/...> include style and stale upstream content): SpeculatedType.h, IncrementalSweeper.h, VM.h, JSModuleRecord.h, WasmIPIntSlowPaths.cpp, UnifiedWebPreferences.yaml, NodesCodegen.cpp. Resolved by taking upstream for the conflict region only, preserving all auto-merged USE(BUN_JSC_ADDITIONS) blocks elsewhere in the file. emit_intrinsic_getInternalField in NodesCodegen.cpp is a real fork addition (Bun's @getInternalField bytecode intrinsic) and was kept; the adjacent asyncFromSyncIteratorInternalFieldIndex helper was stale upstream code and dropped.

JSONAtomStringCacheInlines.h keeps the fork's fallible tryCreateUninitialized path (#317) rather than upstream's create8BitIfPossible, so JSON.parse of an unallocatable string still throws instead of crashing.

JSMicrotask.cpp: upstream introduced settleDriverWithIteratorResult (cached iterator-result object for cooperative drivers, bug 319817) and rewrote the AsyncFromSyncIterator continuation path (bug 319435). Adapted the fork's AsyncContextSwapScope wrapping:

• settleDriverWithIteratorResult now takes JSGlobalObject* and wraps target with the current async context internally; the unwrapped target is still used for the cached-result identity check so the reuse optimisation is kept.
• asyncGeneratorCompleteStep / enqueueAsyncGeneratorDriver call the helper instead of inlining the resolve path.
• InternalMicrotask::AsyncFromSyncIterator{Continue,Done} unwrap the tuple (resolveWithInternalMicrotaskForAsyncAwait wraps the iterator on the scheduling side) before the new JSAsyncFromSyncIterator* cast.
• InternalMicrotask::AsyncModuleExecutionResume ported to the new no-scope asyncModuleExecutionResume signature.

Follow-up fixes for upstream API changes

• AbstractModuleRecord::setImportedModule drops the m_dependencies write; m_loadedModules is the only lookup map now (bug 320144).
• NodesCodegen.cpp restores emit_intrinsic_getInternalField after the conflict-region resolution.

Bun-side changes required by this merge live in the companion oven-sh/bun PR.

[claude]

🔴 The AsyncContextSwapScope adaptation missed two new AsyncGeneratorDriverResume scheduling sites introduced by upstream's AsyncFromSyncIterator rewrite (bug 319435): JSMicrotask.cpp:376 (asyncFromSyncIteratorContinueOrDone Rejected branch) and AsyncFromSyncIteratorPrototype.cpp:291 (driveAsyncFromSyncIteratorWithDriver sync-throws branch) both pass the raw driver instead of AsyncContextSwapScope::wrapWithCurrent(...). As a result, Bun's AsyncLocalStorage snapshot is dropped when a for await over a sync iterable rejects (rejected-promise element or sync next() throws). Both sites should wrap the driver under #if USE(BUN_JSC_ADDITIONS), mirroring JSMicrotask.cpp:552-558. (Anchored to a test file because JSMicrotask.cpp is beyond the 300-file diff window.)

Extended reasoning...

What the bug is

The fork's convention (established in this PR's own adaptation) is that every context value passed to InternalMicrotask::AsyncGeneratorDriverResume is wrapped with AsyncContextSwapScope::wrapWithCurrent(vm, globalObject, driver) so that the receive-side handler can restore Bun's async context before resuming the driver. The receive side at JSMicrotask.cpp:2086-2092 does:

case InternalMicrotask::AsyncGeneratorDriverResume: {
    JSValue contextArg = arguments[2];
#if USE(BUN_JSC_ADDITIONS)
    AsyncContextSwapScope asyncContextScope(vm, globalObject, AsyncContextSwapScope::unwrapContextTuple(contextArg));
#endif
    ...
}

The PR correctly applied this to settleDriverWithIteratorResult (line 309-316) and to asyncGeneratorCompleteStep's isThrow path (line 552-558). But upstream's bug 319435 rewrite introduced two additional AsyncGeneratorDriverResume scheduling sites that were left unwrapped.

The two affected sites

Site 1 — JSMicrotask.cpp:376, in asyncFromSyncIteratorContinueOrDone's Rejected / non-JSPromise-target branch:

JSPromise::rejectWithInternalMicrotask(vm, globalObject, result, InternalMicrotask::AsyncGeneratorDriverResume, target);

Here target is the raw driver from iterator->extractTarget(). This runs inside the AsyncFromSyncIteratorContinue/Done microtask handler, which has restored the async context (line 2036), so wrapWithCurrent at this point would capture a live snapshot — but it is never called.

Site 2 — AsyncFromSyncIteratorPrototype.cpp:291, in driveAsyncFromSyncIteratorWithDriver's exception branch:

JSPromise::rejectWithInternalMicrotask(vm, globalObject, error, InternalMicrotask::AsyncGeneratorDriverResume, driver);

This is called synchronously from op_async_iterator_next inside the driver body, where the async context is active.

rejectWithInternalMicrotask (JSPromise.cpp:1048-1051) does not wrap its context — only resolveWithInternalMicrotaskForAsyncAwait does (line 967-971). So both sites queue the raw driver directly.

Why existing code doesn't prevent it

When the AsyncGeneratorDriverResume microtask fires, unwrapContextTuple(contextArg) (AsyncContextSwapScope.h:82-91) sees a non-InternalFieldTuple, leaves contextArg untouched (so the driver still resumes correctly), and returns jsUndefined(). The AsyncContextSwapScope constructor then early-returns on undefined (line 52-53) and installs no context. There is no crash — unwrapContextTuple is graceful — but the driver's rejection continuation runs with whatever async context happens to be ambient at microtask time, not the snapshot from the await point.

Step-by-step proof

Under USE(BUN_JSC_ADDITIONS):

await asyncLocalStorage.run(store, async () => {
  try {
    for await (const x of [Promise.reject(err)]) {}
  } catch (e) {
    asyncLocalStorage.getStore();  // -> undefined, expected: store
  }
});

1. for await opens an async-from-sync wrapper over the array; the driver is the enclosing async function.
2. The wrapper's next() yields Promise.reject(err); awaitAndContinue schedules AsyncFromSyncIteratorContinue (context wrapped by resolveWithInternalMicrotaskForAsyncAwait).
3. That microtask runs with the async context restored, calls asyncFromSyncIteratorContinueOrDone with Status::Rejected, and reaches line 376.
4. Line 376 queues AsyncGeneratorDriverResume with the raw target.
5. The driver-resume microtask runs: unwrapContextTuple returns jsUndefined(), no context is installed, and the driver's catch block executes with no AsyncLocalStorage store.

Site 2 triggers the same way when the sync iterator's next() itself throws, e.g. { [Symbol.iterator]() { return { next() { throw err } } } } — driveSyncIterator throws, catchScope catches it, and line 291 queues the raw driver.

Impact and fix

This is a Bun-specific behavioural regression vs. the pre-merge fork, where the equivalent reject path (asyncGeneratorCompleteStep isThrow) wrapped the target. It affects Bun's core Node.js-compat AsyncLocalStorage feature on the (common) error paths of for await over sync iterables.

Fix: at both sites, wrap the driver under #if USE(BUN_JSC_ADDITIONS), mirroring lines 552-558:

#if USE(BUN_JSC_ADDITIONS)
    JSValue wrappedTarget = AsyncContextSwapScope::wrapWithCurrent(vm, globalObject, target);
#else
    JSValue wrappedTarget = target;
#endif
    JSPromise::rejectWithInternalMicrotask(vm, globalObject, result, InternalMicrotask::AsyncGeneratorDriverResume, wrappedTarget);

[github-actions]

Preview Builds

Commit	Release	Date
f8c38e23	autobuild-preview-pr-352-f8c38e23	2026-07-26 13:06:16 UTC
642e4852	autobuild-preview-pr-352-642e4852	2026-07-26 11:15:49 UTC
39744305	autobuild-preview-pr-352-39744305	2026-07-26 09:40:19 UTC