Repository navigation
Upgrade WebKit to 7b485a76e9 #43882
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrade WebKit to 7b485a76e9 #43882
Changes from all commits
73618b9
c59bd5d
253498e
336f019
e8f29f9
6981c0a
1783628
2485e4e
cbc7da0
701805b
f17c171
07e4a6c
b2c031c
05411f8
e795bac
07e92bb
bb32fe2
5a659db
6786486
5599f05
efdc463
c8448eb
f226244
8aee5a0
62c5767
c5349a1
3ad6806
83cd52a
412965d
c202477
a3aa45f
f4d56ee
5e20ed2
3067a6e
303040f
6f9fc95
aeef738
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -442,12 +442,16 @@ ipint_simd_i8x16_relaxed_swizzle [AVX] | |
|
|
||
|
|
||
| # ---------------------------------------------------------------------------- | ||
| # JSC IPInt atomics. cmpxchg loop reloads the SIMD accumulator with vmovdqu | ||
| # after the IPInt metadata removal in upstream ef40cabc28d2; gated behind | ||
| # Options::useWasmSIMD(). | ||
| # JSC IPInt out-of-line slow paths. They have local labels only, so the scanner | ||
| # counts them as part of the last global symbol in front of them. Since | ||
| # upstream 5ad2bece76 that symbol is the out-of-line memory.atomic.wait64 | ||
| # handler (it was ipint_i64_atomic_rmw32_cmpxchg_u). The AVX instructions are | ||
| # the splats of .simd_v128_load{8,16,32,64}_splat_slow_path, which only SIMD | ||
| # opcodes reach. Gate: Options::useWasmSIMD(), which Options.cpp turns off | ||
| # when isX86_64_AVX() is false. | ||
| # (1 symbols) | ||
| # ---------------------------------------------------------------------------- | ||
| ipint_i64_atomic_rmw32_cmpxchg_u [AVX] | ||
| ipint_op_memory_atomic_wait64 [AVX] | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 🟡 nit (optional): if the Windows x64 profile binary has the same IPInt reorder as Linux, the windows-x64 verify-baseline CI step fails after this merge. The diff renames only the Linux entry at scripts/verify-baseline-static/allowlist-x64.txt:454 to ipint_op_memory_atomic_wait64 for upstream 5ad2bece76, while scripts/verify-baseline-static/allowlist-x64-windows.txt:428 still names ipint_i64_atomic_rmw32_cmpxchg_u_atomic_validate. Fix: rescan the windows-x64 bun-profile.exe built with the new WebKit pin and move that Windows entry to whichever _validate symbol now precedes the v128.load*_splat slow paths, so both x64 allowlists follow the same upstream layout. Why this was flaggedThe Windows allowlist is generated from the same JSC offlineasm as the Linux one (its header says symbol names only differ by MSVC mangling and a _validate suffix), and its IPInt SIMD entries at scripts/verify-baseline-static/allowlist-x64-windows.txt:405-419 mirror the Linux ones one for one. The Linux commit 253498e explains that the AVX splat slow paths have local labels only and are attributed to the last global symbol before them, which upstream 5ad2bece76 changed from ipint_i64_atomic_rmw32_cmpxchg_u to ipint_op_memory_atomic_wait64. The Windows list at :428 still allowlists ipint_i64_atomic_rmw32_cmpxchg_u_atomic_validate and has no wait64 entry. scripts/verify-baseline-static/src/main.rs:1223-1233 returns FAIL for any violation not in the allowlist (stale entries only print), and .buildkite/ci.ts:673 runs verify-baseline for windows x64, so the Windows step reports the splat AVX instructions under the new symbol and fails, where the base branch with the old WebKit pin passed. Condition I could not check from this checkout: that the Windows prebuilt's global label order moved the… Verification: nit — triggered when CI runs the windows-x64 verify-baseline step on a bun-profile.exe built from the new WebKit pin (which it does on every PR/main build: |
||
|
|
||
|
|
||
| # ---------------------------------------------------------------------------- | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -859,6 +859,14 @@ export const internalModulesLoadedFromBytecode: () => number = $newCppFunction( | |
| 0, | ||
| ); | ||
|
|
||
| // Whether the source of `fn` knows where its lines start. Before anything asked for a position in it, that means they | ||
| // came with its code: from the parse, or out of the bytecode. | ||
|
Comment on lines
+862
to
+863
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If you need a paragraph-long comment to justify why the workaround is OK, the code is wrong — fix the code |
||
| export const sourceHasLineStarts: (fn: Function) => boolean = $newCppFunction( | ||
| "ZigSourceProvider.cpp", | ||
| "jsSourceHasLineStarts", | ||
| 1, | ||
| ); | ||
|
|
||
| // The bytecode `bun build --compile --bytecode` embeds for a builtin module, plus the external string table it embeds | ||
| // beside it: internal module number `index` (null past the last), or `source` written in builtin syntax (@-intrinsics, | ||
| // a function expression) compiled under `name`. | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🟡 nit (optional): an operator running ci-image.ts with a rejected Azure client secret now waits about 14 s through five retries before seeing "Azure auth failed: 401", where the base failed at once. request() at scripts/agent.ts:126 treats only 400, 404, 409 and 422 as final, so the token endpoint's 401 (invalid_client) is retried azureAttempts times with growing sleeps at scripts/agent.ts:109. Fix: treat authentication and authorization answers (401, 403) as final in request(), or pass attempts: 1 for the token request at scripts/ci-image.ts:102, while still retrying network failures and 5xx from the metadata and secret services.
Why this was flagged
An operator runs scripts/ci-image.ts with a wrong AZURE_CLIENT_SECRET. getAzure() at scripts/ci-image.ts:91-102 now calls request() with attempts: azureAttempts (5) instead of a single fetch. login.microsoftonline.com answers 401 with invalid_client, which is not in the final-status list at scripts/agent.ts:126, so the loop at scripts/agent.ts:107-129 repeats the POST four more times with sleeps of 2, 3, 4 and 5 seconds. Only after that does scripts/ci-image.ts:106-109 throw "Azure auth failed: 401". On the base branch the single fetch's !response.ok threw the same message immediately. No safeguard stops the retries because the status list was written for the metadata service, not for an auth endpoint whose 401 is a definitive answer.
Verification: nit. Trigger: an operator runs scripts/ci-image.ts with a wrong AZURE_CLIENT_SECRET (or an expired bearer token on the gallery calls). Mechanism verified: getAzure() at /home/claude/bun/scripts/ci-image.ts:90-101 now calls request() with
attempts: azureAttempts(5, defined at line 70) where the base did a singlefetchand threw on!response.okat once. In… | nit. Trigger: an operator/CI run…There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This line is in the maintainer's commit
8aee5a03e8, and he makes the changes outsidetest/on this branch, so I leave the decision to him. One fact for that decision:scripts/agent.tsis copied onto every machine image, so a change torequest()gives every image a new name, and the next build bakes them all again (about an hour for the Windows ones).