Carbon toolchain environment drift without pinned dependencies

Question

Developing with Carbon currently requires building the toolchain from source using Bazel, Clang, and Python. Because the project is in an experimental phase, the documentation lacks pinned dependency lockfiles, release tags, or container digests to ensure a repeatable development environment.
Without a mechanism to lock the toolchain versions or standard library requirements, a clean build is susceptible to drift as the main branch evolves. This creates a scenario where the same source code may compile successfully in one environment but exhibit different behavior in another based on the local toolchain state.
What are the recommended strategies for freezing the Carbon build environment to ensure consistency across commits? How does the project handle breaking changes in the stdlib API surface when the toolchain is updated independently?

Tasadduq Burney · Answer

Recommended freeze strategy
There is no official Carbon lockfile, release tag, or container digest that guarantees a repeatable build environment. Consistency is operator-owned until the project publishes one. Pin the toolchain and the Carbon source at the same known commit, and treat that combination as a single immutable unit.
What to pin

Carbon repository commit SHA, not main.
Bazel version, declared in .bazelversion or pinned in WORKSPACE.
Clang/LLVM toolchain revision or exact release.
Python interpreter version used by build scripts and code generation.
Third-party dependencies fetched by the build, with checksums where possible.

How to enforce it

Record the Carbon SHA and every toolchain version in CI alongside the commit being tested.
Build from a clean container or hermetic sandbox built from an immutable base image digest, so local system packages are not picked up.
Archive the pinned toolchain tarballs or container image and reuse them for rebuilds of the same commit.
Rebuild the same pinned commit in a second clean environment and compare build exit codes, test results, and artifact hashes. Any difference is environment drift, not a source change.

Verification
bazel --version
clang --version
python3 --version

Record these outputs with the Carbon commit SHA. Rebuild in a second clean container using the same pins and compare artifact hashes.
Stdlib breaking changes
The standard library API surface is tied to the compiler version. Carbon has no documented independent semver or stability policy for the stdlib, so updating Clang/LLVM or the compiler independently can introduce breaking stdlib changes even when Carbon source is unchanged. Pin the compiler and stdlib at the same known commit, and run the compiler and stdlib test suites against that pair before promoting any toolchain update to developers.
Assumptions and uncertainty
This guidance assumes Carbon remains pre-1.0 and experimental, with no published pinning contract. The absence of an official lockfile has not been verified against the live repository; treat it as operator-owned until confirmed. Mixing a main-branch Carbon checkout with an older pinned toolchain is unsupported because compatibility is not versioned.
Missing diagnostic detail
Are you building from a fixed commit SHA or tracking main? If you track main, pinning the Carbon SHA is not possible, and the only controllable variables are the toolchain versions.

Carbon toolchain environment drift without pinned dependencies

1 answer

Recommended freeze strategy

What to pin

How to enforce it

Verification

Stdlib breaking changes

Assumptions and uncertainty

Missing diagnostic detail

Your perspective belongs here.

1 question comment