Error instead of crashing on deeply nested TypeScript types in the transpiler

[robobun]

Problem

Parser fuzzing found a 33 KB TSX input that kills the process with a hard SIGSEGV (sig:SIGSEGV:nostack) instead of a JavaScript error:

bun -e 'new Bun.Transpiler({loader:"tsx", target:"bun", minifyWhitespace:true, deadCodeElimination:true}).transformSync(Buffer.from(Bun.gunzipSync(Buffer.from("H4sIAAAAAAACA+3WMYrCQBSAYWvBO7wLiAYTo3GRPYSdWAQdRBCLJIgge3fdA4g2gsj3PZjmwRQzzb9eAwDwOX5WkS5dOu3a8BjvMIzXZ/lwest4NqNR/HZ1s09dFanN3nDlLM+nZZ6Py0k5nhdFNs2KQd8PAwDIe3kv7wEAkPfyXt4DACDv5b28BwCQ98h7eQ8AIO+R9wAAyHt5L+8BAJD38l7eAwDIe3kv7+U9AIC8R97f836Xtse6SXGum6iruP4fbdccTvv4W9zXGwAA+HI3uJJ58sqBAAA=", "base64"))).toString("latin1"))'

The input is ~28,000 nested [ brackets: 2,462 open an array-literal expression, then <T extends [[[[… makes the TSX parser skip the deeply nested tuple type in the generic arrow function's extends constraint. Reduced shapes hit the same thing:

// all SIGSEGV on a debug build, and on smaller (4 MB worker) stacks in release
new Bun.Transpiler({ loader: "tsx" }).transformSync("<T extends " + "[".repeat(20000) + "0" + "]".repeat(20000) + ">(x: T) => x");
new Bun.Transpiler({ loader: "ts" }).transformSync("type A = " + "[".repeat(20000) + "0" + "]".repeat(20000) + ";");
new Bun.Transpiler({ loader: "ts" }).transformSync("type A = (" + "[".repeat(100000) + "a" + "]".repeat(100000) + ": any) => void;");

Cause

parse_expr_common, parse_binding, parse_stmt, and (since #31242) the visit/print/DCE passes bound their recursion with StackCheck::is_safe_to_recurse(), but the TypeScript type-skipping recursion has no check at all:

• skip_type_script_type_with_opts recurses directly for tuple members, nested generics, object types, conditional types, etc. (parse_skip_typescript.rs, the T::TOpenBracket arm is the frame in the crash backtrace), and
• skip_type_script_binding recurses directly for [/{ destructuring patterns inside skipped function types.

So an AST-free token skip of a deep enough type walks straight off the stack. The crash frame loops in skip_type_script_type_with_opts → skip_type_script_type_with_opts until the guard page is hit, which is why the crash handler prints nothing.

Fix

Add the same guard the sibling parse functions already use to both functions: when is_safe_to_recurse() reports the stack is nearly exhausted, return the StackOverflow error, which the parse entry point already converts into a logged "Maximum call stack size exceeded" error. No behavior change for inputs that fit on the stack; the type skipper allocates no AST, so the check is the only cost per nesting level.

Verification

• Before: the fuzz repro and the reduced shapes above exit with SIGSEGV (exit 139) on a debug/ASAN build; after: they exit cleanly (the fuzz input reports its syntax errors plus "Maximum call stack size exceeded", the valid deep shapes either transpile or throw that error).
• New test deeply nested TypeScript types error instead of crashing the process in test/bundler/transpiler/transpiler.test.js spawns a subprocess that transpiles the TSX generic-arrow shape (bare and nested inside 1,000 array literals, matching the fuzz input), the nested tuple type alias, and the nested function-type destructuring pattern at depths 4,000 / 20,000 / 100,000, and asserts the process exits 0 with no signal. It fails on the unfixed build (child dies with SIGSEGV) and passes with this change.
• bun bd test test/bundler/transpiler/ — 430 pass, 0 fail.

[coderabbitai]

Warning

Review limit reached

@robobun, we couldn't start this review because you've used your available PR reviews for now.

Your plan currently allows 5 reviews/hour. Refill in 46 minutes and 48 seconds.

Your organization has run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

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

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than trial, open-source, and free plans. In all cases, review capacity refills continuously over time.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 35a32545-ce3e-4791-b688-9b9c1fb90ade

📥 Commits

Reviewing files that changed from the base of the PR and between 49c97de and 2a39f71.

📒 Files selected for processing (2)

• src/js_parser/parse/parse_skip_typescript.rs
• test/bundler/transpiler/transpiler.test.js

---

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

[robobun]

^{Updated 7:05 PM PT - May 24th, 2026}

❌ @robobun, your commit 2a39f71 has some failures in Build #57660 (All Failures)

---

🧪   To try this PR locally:

bunx bun-pr 31361

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

bun-31361 --bun

[claude]

LGTM — applies the existing stack_check.is_safe_to_recurse() guard to the two TS type-skipping recursion points that were missing it, with a regression test mirroring the adjacent deep-expression test.

Extended reasoning...

Overview

Two 3-line guards added to skip_type_script_binding and skip_type_script_type_with_opts in src/js_parser/parse/parse_skip_typescript.rs, plus a new subprocess-based regression test in test/bundler/transpiler/transpiler.test.js. The guards return err!("StackOverflow") when self.stack_check.is_safe_to_recurse() reports the stack is nearly exhausted, converting a SIGSEGV on pathologically deep TypeScript types into the existing "Maximum call stack size exceeded" diagnostic.

Security risks

None. This is purely defensive: it removes a denial-of-service vector (process crash on adversarial input) by bounding recursion. No new inputs are accepted, no new code paths are reachable for well-formed inputs, and the error variant is already handled at parse_entry.rs:455/848.

Level of scrutiny

Low. The change is mechanical: the identical if !self.stack_check.is_safe_to_recurse() { return Err(err!("StackOverflow")); } idiom already appears in parse_expr_common (parse/mod.rs:75), parse_binding (parse/mod.rs:974), parse_property (parse_property.rs:256), parse_stmt (parse_stmt.rs:1902), parse_type_script_namespace_stmt (parse_typescript.rs:221), and several visit/DCE passes. This PR simply extends that pattern to two recursive type-skipping functions that were overlooked. Even when the error is swallowed by a lexer_backtracker_* wrapper, the alternative path will hit the same guard at the same stack depth, so the crash is still prevented.

Other factors

• The new test is a near-verbatim copy of the adjacent deeply nested expressions error instead of crashing the process test (same repeat helper, same subprocess spawn, same /Maximum call stack size exceeded|StackOverflow/ check, same [exitCode, signalCode] assertion, same 60s timeout), so it fits established test conventions.
• PR description reports the full transpiler test suite passes (430 pass, 0 fail) and that the test fails on the unfixed build with SIGSEGV.
• No outstanding reviewer comments; no prior reviews from me; no design decisions involved.

[claude]

LGTM — applies the same stack_check.is_safe_to_recurse() guard already used throughout the parser to the two TS type-skipping recursion entry points, with a regression test mirroring the existing deeply-nested-expressions test.

Extended reasoning...

Overview

This PR adds a stack-depth guard to two mutually/self-recursive functions in src/js_parser/parse/parse_skip_typescript.rs (skip_type_script_binding and skip_type_script_type_with_opts) so that pathologically nested TypeScript types produce a "Maximum call stack size exceeded" error instead of a SIGSEGV. It also adds a subprocess-based regression test in test/bundler/transpiler/transpiler.test.js.

Security risks

None. The change only adds an early return Err(err!("StackOverflow")) when the existing StackCheck reports the stack is nearly exhausted. It introduces no new inputs, allocations, or control-flow paths beyond an error return that the parse entry point (parse_entry.rs:455/848) already handles by logging a range error. If anything this is a robustness/DoS hardening fix (crash → recoverable error).

Level of scrutiny

Low-to-medium. While the file is part of the core JS/TS parser, the change is purely additive and mechanical: the exact 3-line if !self.stack_check.is_safe_to_recurse() { return Err(err!("StackOverflow")); } pattern already appears verbatim in parse_binding (mod.rs:974), parse_expr_common (mod.rs:75), parse_property.rs:256, parse_typescript.rs:221, and parse_stmt.rs:1902. The guard is a no-op until stack headroom is exhausted, so normal inputs are unaffected. The StackOverflow error returned inside backtracking contexts (lexer_backtracker_bool) is treated as a backtrack, which is consistent with how the sibling guarded functions already behave and still terminates because the alternate path re-hits the same guard at the same depth.

Other factors

• The new test is structurally identical to the immediately preceding deeply nested expressions error instead of crashing the process test (same repeat helper, same subprocess spawn, same /Maximum call stack size exceeded|StackOverflow/ error filter, same [exitCode, signalCode] assertion), so it follows established conventions.
• No CODEOWNERS entry covers these paths.
• The bug-hunting system found no issues.
• The robobun comment shows CI failures on the first commit, but a ci: retrigger commit was pushed; given the change cannot affect anything until the stack is nearly full, any failures are almost certainly unrelated/flaky.

[robobun]

CI status for this PR: the diff itself is green.

• Every test lane that actually executed passes on both builds (57651 and 57660 after the retrigger): all Linux lanes including debian-13-x64-asan (the one that exercises the new stack-overflow regression test), Alpine, Ubuntu, Windows x64/aarch64, and darwin-14-x64.
• The only red checks are darwin-14-aarch64-test-bun and darwin-26-aarch64-test-bun, which show "Expired" with 0 s duration on both builds — the jobs never got a macOS aarch64 agent and never ran any tests. That's runner capacity, unrelated to this change (a parser stack-check guard plus a JS test).

Needs a maintainer to either retry those two Buildkite jobs or merge as-is.