Toolchain Coverage

Toolchain Coverage

Source of truth for “can we build language X on GloriousFlywheel?”

Snapshot date: 2026-05-10.

This page describes Bazel-hermetic toolchain coverage. It is not a claim about RBE eligibility — that lives in config/rbe-target-eligibility.json and is owned by the Codex proof-and-guard stream. Cache-backed CI on shared runners is governed by the runner-cache contract, not by this page.

The Worker Toolchain Model records the current REAPI proof image contents. A tool being present in that worker image does not promote a language family: every target class still needs a forced REAPI proof before it becomes RBE-eligible.

Status table

Language Status Bazel rules Source Proof target Notes
TypeScript / JavaScript Hermetic aspect_rules_js 2.9.2, aspect_rules_ts 3.8.3, rules_nodejs 6.7.3 Pinned Node 22.13.1 + pnpm //app:build, //docs-site:build Cache-backed CI green; //app:build also drives the narrow gf-reapi-cell proof
Python Hermetic rules_python 1.4.1 Pinned interpreter 3.11 via rules_python (utility/tooling only) python.toolchain(python_version="3.11", ignore_root_user_error=True) registered
Shell Hermetic rules_shell 0.6.0 Nix-provided coreutils via flake (test scripts) Used for contract tests
Rust Hermetic (BCR) rules_rust 0.70.0 (BCR) rules_rust hermetic toolchain (downloaded prebuilt rustc/cargo); not Nix-sourced //examples/hello-rust:hello, //examples/hello-rust:hello_test Binary wedge landed 2026-05-09; Stage 1 cache-backed test target added 2026-05-10. Forced REAPI run 25648670844 proved the trivial Rust unit-test class with 5 remote processes after earlier runs exposed libz.so.1 and Nix gcc-wrapper worker-closure gaps. This is narrow target-class proof, not all Rust. rules_nixpkgs_rust is not in BCR — see Definitions below
C / C++ Narrow REAPI-proved rules_cc 0.2.18 (BCR) System/Nix cc toolchain auto-resolved via --incompatible_enable_cc_toolchain_resolution; remote proof depends on the pinned worker image carrying the C/C++ wrapper closure //examples/hello-cc:hello, //examples/hello-cc:hello_test Binary wedge landed 2026-05-09; Stage 1 cache-backed test target added 2026-05-10. Forced REAPI run 25638930305 reached the remote C++ compile action for //examples/hello-cc:hello_test, then failed because the Nix gcc-wrapper path was not present in the worker. After the worker image carried the C/C++ closure, run 25648975728 proved the trivial C++ unit-test class with 4 remote processes. This is one target-class proof, not all C++.
Go Narrow REAPI-proved rules_go 0.60.0 (BCR) rules_go hermetic Go SDK (downloaded prebuilt); cgo proof depends on the pinned worker image carrying the C/C++ wrapper closure; not Nix-sourced //examples/hello-go:hello, //examples/hello-go:hello_test, //examples/hello-go-cgo:cgo_test Binary wedge landed 2026-05-09; Stage 1 cache-backed test target added 2026-05-10. Forced REAPI run 25634296833 proved the pure-Go //examples/hello-go:hello_test class with 11 remote processes. Earlier run 25632300253 exposed a runtime/cgo / cc: no such file or directory worker/toolchain gap; after the worker image carried the C/C++ closure, run 25649628233 proved the trivial cgo-backed Go class with 11 remote processes. gf-reapi-cell still builds via buildGo124Module in flake by design
Zig Backlog (none) (none) — No rules_zig and no Nix devshell wiring today
Chapel Backlog (none) (none) — No rules_chapel exists upstream; would need a nixpkgs_package shim

Definitions

  • Hermetic: Bazel resolves a registered toolchain that does not depend on ambient $PATH. The toolchain binaries come from a pinned source (Bazel registry, Nix flake attribute, or pinned http_archive).
  • Hermetic (BCR): subset of hermetic where the toolchain is sourced via a BCR-published bazel_dep (e.g. rules_rust’s prebuilt toolchain). This is hermetic in the Bazel sense but is not Nix-sourced — the rustc/cargo binaries come from rules_rust mirrors. Distinguished because the original sprint plan aspired to Nix-sourced toolchains via the rules_nixpkgs_* family, which turned out not to be in BCR.
  • Cache-backed only: a target class is useful on the shared cache-backed runner contract but has not proved remote worker toolchain availability.
  • Narrow REAPI-proved: one or more target classes have a forced REAPI proof with nonzero remote processes, but the language/toolchain family is not broadly remote-hermetic. C++ and cgo-backed Go currently fall here because the proof relies on the pinned worker image carrying the selected Nix C/C++ closure.
  • Not yet hermetic: builds may succeed when a system or Nix-shell-provided compiler is on $PATH, but Bazel does not register a sealed toolchain. This means cross-machine reproducibility is best-effort, not contract.
  • Backlog: no current proof, no planned wedge this sprint. Re-evaluate when rust/cc/go land cleanly.

Coordination

The C1 toolchain wedge in docs/superpowers/plans/2026-05-10-cache-forward-toward-rbe.md lands as three sequential PRs (rust → c++ → go). When each PR merges, update the corresponding row’s Status from Not yet hermetic to Hermetic and fill in the Proof target column with the merged target name.

The Stage 1 test wedge adds one trivial test target per landed BCR language. Those tests are cache-backed proof targets in Source Bazel Proof; they are not RBE proof until the eligibility manifest records a forced REAPI run with nonzero remote processes.

RBE eligibility for any of these toolchains is a separate question. Codex owns config/rbe-target-eligibility.json; this page does not promote a target to RBE-eligible.

GloriousFlywheel