[sosukesuzuki]

Summary

• Each crate's rustc frontend (parse, macro expansion, name resolution, type/borrow check, MIR) runs single-threaded by default. Cargo parallelizes across crates and rustc parallelizes codegen across codegen-units, but the frontend does not.
• The workspace crate graph is a funnel: ~110 crates collapse into a few large leaf crates (bun_runtime, bun_css, bun_bundler) that cannot start until their transitive deps finish. The tail of every cargo build is one large crate's frontend pinned to a single core while the rest of the machine sits idle.
• -Zthreads=8 parallelizes that frontend. It is nightly-only, but the toolchain is already pinned to nightly and the build already passes -Zbuild-std, -Zsanitizer, and -Zlocation-detail, so this adds no new constraint.

Test plan

• bun bd completes successfully (full debug build, no rustc ICE)
• Resulting bun-debug runs (--revision and a basic JS eval)
• Confirm -Zthreads=8 is present in the cargo CARGO_ENCODED_RUSTFLAGS of generated build.ninja
• Benchmark clean cargo build wall-time on an idle machine, baseline vs. this change, interleaved and median-of-N
• CI green across targets (the rust-only job in particular)

[robobun]

^{Updated 3:22 AM PT - May 15th, 2026}

❌ @sosukesuzuki, your commit 33c4c8c has 1 failures in Build #54565 (All Failures):

• test/js/node/http/node-http-backpressure-max.test.ts - code 1 on 🍎 14 x64

---

🧪   To try this PR locally:

bunx bun-pr 30761

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

bun-30761 --bun

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 6c8d792b-c9a7-46b9-8c07-df34aedc42e3

📥 Commits

Reviewing files that changed from the base of the PR and between bbd3e62 and 33c4c8c.

📒 Files selected for processing (1)

• scripts/build/rust.ts

---

Walkthrough

This PR adds the nightly-only rustc flag -Zthreads=8 to the Rust build configuration in scripts/build/rust.ts, enabling parallel execution of the rustc frontend during cargo builds to improve compilation performance.

Changes

Rust build parallelization

Layer / File(s)	Summary
Rustc parallelization flag scripts/build/rust.ts	The emitRust function now includes the -Zthreads=8 rustc flag in rustflags to enable parallelization of the rustc frontend during cargo builds.

🚥 Pre-merge checks | ✅ 3 | ❌ 1

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Description check	❓ Inconclusive	The PR description provides context, motivation, and a detailed test plan, but lacks explicit sections matching the required template structure.	Reorganize the description to clearly map to template sections: add 'What does this PR do?' heading for the Summary section, and 'How did you verify your code works?' heading for the Test plan section.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately summarizes the main change: enabling parallel rustc frontend via the -Zthreads=8 flag in the build process.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

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

[claude]

LGTM — straightforward build flag addition consistent with the other nightly -Z flags already in this file.

Extended reasoning...

Overview

This PR adds a single rustflag, -Zthreads=8, to the CARGO_ENCODED_RUSTFLAGS assembled in scripts/build/rust.ts. It enables rustc's parallel frontend to speed up the tail of cargo builds where large leaf crates (bun_runtime, bun_css, bun_bundler) are compiled serially. The change is two lines (one comment, one rustflags.push) inserted alongside the existing -Ctarget-cpu push.

Security risks

None. This is a build-system-only change that affects compiler parallelism, not the semantics of generated code. It touches no auth, crypto, network, or runtime logic.

Level of scrutiny

Low. The file already passes multiple nightly-only -Z flags (-Zbuild-std, -Zsanitizer, -Zlocation-detail, -Zsplit-lto-unit, -Zunstable-options), and the toolchain is pinned to nightly via rust-toolchain.toml, so adding -Zthreads introduces no new toolchain constraint. The flag is appended unconditionally in the same style as -Cforce-frame-pointers and -Cllvm-args=-addrsig just above it, following the established pattern exactly.

Other factors

The worst-case failure mode is a rustc ICE or build regression, both of which CI will surface immediately (the PR description explicitly lists CI green and bun bd as test-plan items). No CODEOWNERS cover scripts/build/. The bug-hunting system found no issues. Given the change is mechanical, self-contained, and only affects build wall-time, this is safe to approve without human review.

[RiskyMH]

I wonder if it should check os.availableParallelism() and only use if 8+ to avoid overloading on less powerful builds

[robobun]

Landed on main via #31096, so closing this one. One difference: #31096 gates -Zthreads=8 on !cfg.ci (local builds only), while this PR enabled it for CI builds as well. #31096 keeps CI on the serial frontend on purpose (stable diagnostic ordering, no -Z flag on shipped builds), so enabling it in CI would be a separate change if anyone wants it.