Pin the toolchain and stop shipping machine-specific state (review PRs 1 + 2)

[codeitlikemiley]

Three independently reviewable commits from the build-system review. Read them one at a time — they do unrelated work.

• 1a4844f PR 1 — stop shipping generated and machine-local files
• a73a9ac PR 2 — pin the Rust toolchain, the edition and the Bazel version
• 47e8810 PR 2 follow-up — .bazelrc amendments after running Bazel end to end

Why

Bazel and Cargo were not building the same program. The most consequential case: every Cargo.toml says edition = "2024", but no BUILD target set edition and no rust.toolchain() was registered, so rules_rust fell back to its own rust.toolchain(edition = "2021") at DEFAULT_RUST_VERSION = "1.86.0". The rust-project.json that was committed to this repo — produced by a real gen_rust_project run — confirms it: all five first-party crates carried "edition": "2021" with a rust_analyzer_1.86.0_tools sysroot, while cargo reports 1.94.1.

That is not only a syntax-compatibility gap. Demonstrated with rustc 1.94.1: an if let holding a MutexGuard whose else arm re-locks deadlocks under --edition 2021 and completes under --edition 2024, because 2024 changed when the scrutinee temporary is dropped. cargo test would pass, bazel test would hang, and nobody could reproduce it locally.

PR 1 — stop shipping machine-specific state

No build logic changes.

Change	Reason
Untrack + gitignore rust-project.json	60 of 65 crate roots pointed into /private/var/tmp/_bazel_uriah/…, 5 into /Users/uriah/Code/yoyo, proc-macros at darwin_arm64 .dylibs. Also 3 commits stale, with 2 dead target labels. rust-analyzer's ProjectManifest::discover returns on finding it and never reaches the Cargo fallback — which works today. Shipping it is worse than not having it.
Harden build-ra.sh	set -euo pipefail, resolve the repo root, prefer bazelisk, fail clearly when neither binary is present, accept target patterns.
Clean .cargo-runner.json	Drop linked_projects (5 absolute /Users/uriah paths). Delete combos/.cargo-runner.json — combos/ is a virtual workspace root with no [package]. Strip combos/frontend's override, whose match.file_path is another absolute path that can never fire.
.gitignore	Delete the *.md catch-all — it silently swallowed every future doc. Delete cargo-bazel-lock.json, which is the crate_universe lockfile artifact and must be committed. .vscode/ → .vscode/* + negations. Remove the 5 byte-identical leaf .gitignore files.
README IDE section	It pointed at three things that don't exist (.vscode/tasks.json, a Cmd+R Cmd+R binding, ./refresh-rust-analyzer.sh) and told readers to hand-write "rust-analyzer.linkedProjects": ["rust-project.json"] — which would now point at nothing and suppress the working fallback.

Verified with git check-ignore that target/, bazel-*, .DS_Store and rust-project.json are still ignored at every depth from the root file alone, and that CONTRIBUTING.md is now addable.

PR 2 — pin the toolchain

• MODULE.bazel — rust.toolchain(edition = "2024", versions = ["1.94.1"], sha256s = {…}) + register_toolchains. Pinned to 1.94.1, the version verified to build all three workspaces, rather than latest (1.97.1).
• sha256s (27 entries) — rules_rust 0.63.0 predates 1.94.1, so known_shas.bzl has no entry and repository_utils.bzl:516-521 would download the toolchain unverified. Hashes come from the channel manifest at static.rust-lang.org.
• rust-toolchain.toml at the same version, plus rust-version = "1.94" in all four [package] tables.
• edition = "2024" on all nine source-compiling targets. Deliberately not on the five rust_test(crate = …) targets — rust.bzl:374 makes them inherit crate.edition, so it would be a no-op there.
• .bazelversion — 8.7.0. Not 9.x: rules_rust 0.63.0 predates it and declares a 7.4.1 minimum in its own CI config.
• .bazelrc — the base config the repo never had, though .gitignore already reserved .bazelrc.user. Notably --compilation_mode=dbg, since Bazel's default fastbuild is opt-level 0 with no debug info while cargo's dev profile is -C debuginfo=2.
• .bazelignore, and MODULE.bazel.lock is no longer ignored.
• tools/pin_rust_toolchain.py — regenerates the hash dict so a version bump is one command.

One proposed flag was dropped after checking it

--incompatible_strict_action_env does not exist in Bazel 8.7.0 (absent from CoreOptions.java). It would have broken every invocation. Every other flag was verified present in Bazel 8.7.0 or in rules_rust 0.63.0's rust/settings/settings.bzl.

--@rules_rust//rust/settings:clippy.toml=//:clippy.toml and its rustfmt twin remain deferred — those files don't exist yet and the root BUILD.bazel exports nothing, so the label_flag in @rules_rust//rust/settings can't see them.

Verification — Bazel was run end to end

Bazel 8.7.0 installed from the official APT bucket on storage.googleapis.com (SHA256 matching the published index). bcr.bazel.build is unreachable from the build environment, so module metadata came from a local mirror of bazelbuild/bazel-central-registry with sources redirected to git clones. That scaffolding is entirely outside the repo plus a gitignored .bazelrc.user; none of it is committed.

Check	Result
bazel build //...	OK — 603 actions, 17 targets
bazel test //...	9 of 9 pass
bazel build --config=release //...	OK
bazel build --config=ci //...	OK
gen_rust_project	all 8 first-party crates edition=2024; sysroot rust_analyzer_1.94.1_tools
toolchain integrity	tampering one sha256s entry fails the fetch with a checksum mismatch
cargo side	cargo build --all-targets + cargo test --locked pass in all three workspaces; no Cargo.lock changed

The central claim is now measured rather than argued:

backend_bin edition=2024   frontend_bin edition=2024   corex        edition=2024
bench       edition=2024   axum_example edition=2024   proxy        edition=2024
server_bin  edition=2024   integration_tests_tests_just_test_test edition=2024

EDITIONS ACROSS FIRST-PARTY: {'2024'}

The sha256s block needed proving specifically, because a wrong key degrades silently to an unverified download rather than failing. Corrupting one entry and rebuilding with a cold repository cache gives Checksum was 0a6b16ca…87e1 but wanted 0000…, and 0a6b16ca…87e1 is exactly what tools/pin_rust_toolchain.py emits — so the keys match produce_tool_path() and the hashes are enforced.

Not verified

bazel coverage, for an environment reason only: Bazel's own coverage_output_generator is hosted on mirror.bazel.build, which the build environment's egress policy blocks with a 403. The coverage flags parse.

MODULE.bazel.lock is deliberately not committed

It generates fine, but the build ran against a file:// registry, so Bazel records no registry file hashes — registryFileHashes is empty where a real BCR build records thousands — and its moduleExtensions entries were evaluated against git clones rather than release artifacts. Committing it would look like progress while guaranteeing failure the moment CI enables --lockfile_mode=error. It must be generated on a machine with real BCR access first; the .bazelrc comment says so.

Known follow-ups (deliberately out of scope)

• Adding lockfile = "//…:cargo-bazel-lock.json" to the three crate.from_cargo tags. PR 1 removed the .gitignore line that was pre-blocking it.
• size = "small" on the test targets — all nine are declared MODERATE and finish in ~0.1s. test:ci --test_verbose_timeout_warnings now surfaces this.
• BUILD-file correctness, the server library split, CI, and collapsing the three Cargo.lock files into one workspace — the only fix for server_bin currently linking two distinct serde rlibs.

[codeitlikemiley]

Verified by actually running Bazel

The PR description said Bazel could not run here. That is no longer true — 47e8810 is the follow-up. Bazel 8.7.0 was installed from the official APT bucket on storage.googleapis.com (SHA256 889831cc…a6bd, matching the published index), and bcr.bazel.build was replaced with a local mirror of bazelbuild/bazel-central-registry fetched through the session git proxy, with module sources redirected to git clones. All of that is verification scaffolding in /tmp and a gitignored .bazelrc.user; nothing about it is committed.

Results

Check	Result
bazel build //...	OK — 603 actions, 17 targets, 128s
bazel test //...	9 of 9 pass
bazel build --config=release //...	OK
bazel build --config=ci //...	OK
gen_rust_project	all 8 first-party crates edition=2024; sysroot rust_analyzer_1.94.1_tools
toolchain integrity	tampering one sha256s entry fails the fetch with a checksum mismatch

The central claim of the review is now measured rather than argued:

backend_bin    edition=2024      frontend_bin   edition=2024
corex          edition=2024      bench          edition=2024
axum_example   edition=2024      proxy          edition=2024
server_bin     edition=2024      integration_tests_tests_just_test_test edition=2024

EDITIONS ACROSS FIRST-PARTY: {'2024'}
sysroot: .../rules_rust++rust+rust_analyzer_1.94.1_tools

Before this branch those same crates read edition=2021 with a rust_analyzer_1.86.0 sysroot.

The sha256s block needed proving specifically, because a wrong key degrades silently to an unverified download rather than failing. Corrupting one entry and rebuilding with a cold repository cache gives:

Checksum was 0a6b16ca476461c6238f48efcb74a7aa08a3983e61adf587f208ba48504d87e1
        but wanted 0000000000000000000000000000000000000000000000000000000000000000

0a6b16ca…87e1 is exactly what tools/pin_rust_toolchain.py emitted, so the keys match produce_tool_path() and the hashes are enforced.

What changed as a result

• Added pipelined_compilation — held back in PR 2 as an untested behaviour change; now verified across all 17 targets.
• Added test:ci --test_verbose_timeout_warnings — also previously unverified. Scoped to --config=ci because it is noisy today: every test is declared MODERATE and finishes in ~0.1s, so all nine warn. The fix is size = "small", which belongs to the BUILD-file sweep.

One thing deliberately not done

MODULE.bazel.lock is not committed. It generates fine, but because the build ran against a file:// registry, Bazel records no registry file hashes — registryFileHashes is empty — so this lock would be judged out of date the moment anyone builds against the real BCR. It has to be generated on a machine with BCR access before --config=ci (which sets --lockfile_mode=error) can be switched on. The .bazelrc comment now says so explicitly.

Still unverified

bazel coverage — and only for an environment reason: Bazel's own coverage_output_generator is hosted on mirror.bazel.build, which this sandbox's egress policy blocks with a 403. The coverage flags parse; the tool behind them can't be fetched here.

---

Generated by Claude Code