BigInt("0x…"/"0b…"/"0o…"): linear-time string parse

[robobun]

Depends on oven-sh/WebKit#353.

Problem

BigInt("0x…"), BigInt("0b…"), BigInt("0o…") parse time is O(n²) in the string length. JSBigInt::parseInt routes every radix through a loop that calls multiplyAdd over the full preallocated digit vector once per lengthLimitForBigInt32 characters (n/k groups × O(n) per group). The output direction, toStringBasePowerOfTwo, is already linear.

for (const n of [50_000, 100_000, 200_000]) {
  const s = "f".repeat(n);
  let t = performance.now(); BigInt("0x" + s);
  console.log(n, (performance.now() - t).toFixed(1), "ms");
}

n (hex chars)	bun 1.4.0	node v26.3.0	after
50 000	26.8 ms	0.1 ms	~0.2 ms
100 000	125.5 ms	0.3 ms	~0.4 ms
200 000	362 ms	0.4 ms	~0.7 ms

Sibling of the radix-10 quadratic conversions, split out because the pow-2 fix is trivially linear and independent of any divide-and-conquer work.

Fix

oven-sh/WebKit#353 adds a fast path in JSBigInt::parseInt for power-of-two radix that packs each character's ctz(radix) bits directly into the digit vector, carrying across 64-bit word boundaries for octal. No multiplication. Short inputs that fit in int32 fall through to the existing path so they keep returning BigInt32.

This PR

• Bumps WEBKIT_VERSION (currently pointing at the preview build; will be updated to the merged sha once JSBigInt::parseInt: O(n) fast path for power-of-two radix WebKit#353 lands).
• Adds test/js/bun/jsc/bigint-parse.test.ts: roundtrip correctness for hex/binary/octal at every alignment boundary (1..40 hex, 1..130 binary, 1..70 octal to cover the 3-bit span across 64-bit words), cross-radix agreement, leading-zero/whitespace handling, SyntaxError on bad chars, and a linearity check at 250 000 hex chars (before: ~570 ms release; after: <10 ms debug+ASAN).

Verification

Local debug-local build (WebKit from source, ASAN):

              before       after
50k hex       1097 ms      1.9 ms
100k hex      4365 ms      3.4 ms
200k hex      17405 ms     5.8 ms

All 7 tests pass in 160 ms.

---

[decide:webkit] gate passed · iteration 2 · 2 files touched

passes on PR (with fix)

Test-only change.

Debug/ASAN (expected pass):
$ bun bd test 'test/js/bun/jsc/bigint-parse.test.ts'
$ BUN_DEBUG_QUIET_LOGS=1 bun scripts/build.ts --profile=debug --quiet test test/js/bun/jsc/bigint-parse.test.ts
bun test v1.4.0 (f7c2ba01d)

test/js/bun/jsc/bigint-parse.test.ts:
(pass) BigInt string parse, power-of-two radix > hex correctness [38.50ms]
(pass) BigInt string parse, power-of-two radix > binary correctness [42.07ms]
(pass) BigInt string parse, power-of-two radix > octal correctness (3 bits/char, spans digit boundaries) [42.18ms]
(pass) BigInt string parse, power-of-two radix > cross-radix agreement on large values [4.61ms]
(pass) BigInt string parse, power-of-two radix > leading zeros, whitespace, and 16-bit string storage [7.74ms]
(pass) BigInt string parse, power-of-two radix > maxLength boundary (2^20 bits) [16.84ms]
(pass) BigInt string parse, power-of-two radix > invalid characters still throw SyntaxError [8.84ms]
(pass) BigInt string parse, power-of-two radix > parse is linear, not quadratic [25.33ms]

 8 pass
 0 fail
 348 expect() calls
Ran 8 tests across 1 file. [2.29s]
Exit: 0

diff hotspot

scripts/build/deps/webkit.ts         |   2 +-
 test/js/bun/jsc/bigint-parse.test.ts | 114 +++++++++++++++++++++++++++++++++++
 2 files changed, 115 insertions(+), 1 deletion(-)

gate history · 1 passed · 2 rejected · iteration 2

evidence per changed file

file                                  reads  edits  tests
scripts/build/deps/webkit.ts              3      1      0
test/js/bun/jsc/bigint-parse.test.ts      1      4      0

[coderabbitai]

Warning

Review limit reached

@robobun, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 1 minute

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 60561f9c-478b-4361-9884-86b5eff3924a

📥 Commits

Reviewing files that changed from the base of the PR and between 44f6469 and f7c2ba0.

📒 Files selected for processing (2)

• scripts/build/deps/webkit.ts
• test/js/bun/jsc/bigint-parse.test.ts

---

_{Comment @coderabbitai help to get the list of available commands.}

[robobun]

^{Updated 7:13 AM PT - Jul 26th, 2026}

❌ @robobun, your commit f7c2ba0 has 2 failures in Build #82305 (All Failures):

• test/js/bun/s3/s3.test.ts - crash reported on 🐧 3.23 aarch64
• 📦 Binary size — 12 over 0.50 MB

target	this build	canary: main #79916
		size	Δ
❌ bun-darwin-aarch64	58.13 MB	57.58 MB	+564.9 KB
❌ bun-darwin-x64	63.48 MB	62.95 MB	+544.5 KB
❌ bun-linux-aarch64	70.98 MB	70.42 MB	+576.0 KB
❌ bun-linux-x64	72.47 MB	71.95 MB	+528.0 KB
❌ bun-linux-aarch64-musl	64.88 MB	64.32 MB	+576.0 KB
❌ bun-linux-x64-musl	66.98 MB	66.45 MB	+544.0 KB
❌ bun-linux-aarch64-android	78.47 MB	77.97 MB	+512.0 KB
❌ bun-linux-x64-android	80.62 MB	80.10 MB	+529.2 KB
❌ bun-freebsd-x64	83.07 MB	82.56 MB	+528.0 KB
❌ bun-freebsd-aarch64	84.84 MB	84.31 MB	+544.0 KB
❌ bun-windows-x64	80.26 MB	79.70 MB	+572.0 KB
❌ bun-windows-aarch64	70.86 MB	70.34 MB	+534.5 KB

Add [skip size check] to the commit message if this increase is intentional.

---

🧪   To try this PR locally:

bunx bun-pr 35899

That installs a local version of the PR into your bun-35899 executable, so you can run:

bun-35899 --bun

[robobun]

Status: diff is green; waiting on oven-sh/WebKit#353 to merge so WEBKIT_VERSION can be swapped from the preview tag to the merged sha.

Build #82305 (192/196 passed):

• test/js/bun/jsc/bigint-parse.test.ts passes on every lane.
• binary-size +528-576KB: the baseline is canary #79916 (ae4b17d), which is 12 commits behind this PR's base (44f6469). Those 12 main commits include node:repl (node:repl: replace the stub with Node v26.3.0's REPL — v26 readline stack, acorn recoverable-parse + top-level await, completion, history, --interactive (82 vendored upstream tests) #31827), node:quic (node:quic on lsquic — Node v26 compat, HTTP/3 #32602), and node:inspector (node:inspector: implement Profiler precise coverage and inspector.open() with a DevTools-protocol server #31823), which account for the delta. Other PRs based on the same main show the identical +564/+544/+576 KB deltas (e.g. build #82300). The WebKit tarball difference between autobuild-549170099226 and autobuild-preview-pr-353-4b51ec68 is ~36KB.
• test/js/bun/s3/s3.test.ts on alpine 3.23 aarch64: S3 backend returned InternalError: We encountered an internal error. Please try again. Single lane, unrelated to this change.
• 6 tests marked flaky, all passed on retry.

Local debug-local build (WebKit compiled from source, ASAN):

hex chars	before	after
50 000	1 097 ms	1.9 ms
100 000	4 365 ms	3.4 ms
200 000	17 405 ms	5.8 ms

USE_SYSTEM_BUN=1 bun test test/js/bun/jsc/bigint-parse.test.ts: perf test fails at 576 ms for 250k hex chars (threshold 250 ms). With the bump: all 8 tests pass in ~270 ms under debug+ASAN.

[claude]

🔴 WEBKIT_VERSION is pointing at autobuild-preview-pr-353-4b51ec68, an ephemeral preview-build release for the still-unmerged oven-sh/WebKit#353. Preview releases are deleted once the upstream PR merges/closes, at which point every fresh prebuilt-mode build (CI and local) will 404 on the WebKit download. Per the description this is a known TODO — flagging so it doesn't slip: bump to the merged commit sha before landing.

Extended reasoning...

What the bug is

scripts/build/deps/webkit.ts:6 sets:

export const WEBKIT_VERSION = "autobuild-preview-pr-353-4b51ec68";

replacing the previous 40-hex commit sha. The autobuild-preview-pr-* tag is the CI preview release that oven-sh/WebKit publishes for open PRs so downstream Bun PRs can test against them before the WebKit change lands. These preview releases are ephemeral — they are deleted (or become stale/unreferenced) once the WebKit PR is merged or closed and the real autobuild-<sha> release is published for the merged commit.

Code path that triggers it

prebuiltUrl() in the same file builds the download URL directly from this constant:

const version = cfg.webkitVersion;
const tag = version.startsWith("autobuild-") ? version : `autobuild-${version}`;
return `https://github.com/oven-sh/WebKit/releases/download/${tag}/${name}.tar.gz`;

so every cfg.webkit === "prebuilt" build — which is the default for CI and for anyone not running a local WebKit checkout — fetches https://github.com/oven-sh/WebKit/releases/download/autobuild-preview-pr-353-4b51ec68/bun-webkit-<os>-<arch><suffix>.tar.gz. prebuiltDestDir() also keys the cache dir on this string, so there is no fallback to a previously-cached sha.

Why nothing else prevents it

There is no guard in the build system that rejects preview tags or falls back to a pinned release; prebuiltUrl() explicitly accommodates the autobuild- prefix so preview tags work during development. The only thing preventing this from breaking builds today is that oven-sh/WebKit#353 is still open and its preview artifacts still exist.

Impact

If this PR merges as-is and oven-sh/WebKit#353 subsequently merges (which it must, since this PR depends on it), the preview release will be cleaned up. From that point every fresh clone / cache-cold CI runner hits a 404 downloading WebKit and the build fails outright — a regression in something that currently works on main. Even before deletion, pinning main to an unmerged, force-pushable PR branch is fragile.

Step-by-step proof

1. Merge this PR with WEBKIT_VERSION = "autobuild-preview-pr-353-4b51ec68".
2. JSBigInt::parseInt: O(n) fast path for power-of-two radix WebKit#353 merges; its preview release autobuild-preview-pr-353-4b51ec68 is deleted per the preview-release lifecycle.
3. A contributor (or CI) with a cold cache runs bun bd. resolveDep for WebKit computes prebuiltUrl(cfg) → .../releases/download/autobuild-preview-pr-353-4b51ec68/bun-webkit-linux-amd64.tar.gz.
4. GitHub returns 404; the fetch step fails; the build aborts before compiling anything.
5. Every subsequent PR's CI is red until someone lands a follow-up bumping WEBKIT_VERSION.

Fix

Before merging, land oven-sh/WebKit#353 first, then update this line to the merged commit's 40-hex sha (matching the autobuild-<sha> release), e.g.:

export const WEBKIT_VERSION = "<merged-commit-sha>";

The PR description already states this intent ("will be updated to the merged sha once oven-sh/WebKit#353 lands"); this comment is the merge-blocking reminder so it can't be forgotten.

[robobun]

Yes, intentional and tracked: PR is in draft until oven-sh/WebKit#353 lands, then this line gets swapped to the merged 40-hex sha. Leaving this thread open as the merge-blocker.