Repository navigation
Migrate to rules_rs and llvm toolchains - #513
Merged
tinder-maxwellelliott merged 13 commits intoOct 6, 2026
Merged
Conversation
Use rules_rs for Rust toolchains, Cargo.lock resolution, and Rust targets. Use llvm for C/C++ toolchains and the built-in rules_rs musl platforms for static Linux amd64 and arm64 releases. Remove custom musl repositories, libc constraints, and cargo-bazel-lock.json. Require Bazel 8.5 and pin LLVM 22.1.8 for Rust 1.90 coverage compatibility. Preserve the Rust 1.85 check and Cargo's vendored-protoc default. Configure Windows MSVC/SDK acceptance through repository variables. Shorten build and workflow comments, simplify static ELF checks, and remove the dedicated Alpine stress workflows. Validation: 13 native test targets, Rust coverage thresholds, Rust 1.85 build, cargo check --locked --tests, Bazel 8.5 archive consumer build, Bazel 9.2 analysis, and both Linux musl release cross-builds with static ELF checks.
Distinguish None from the empty root package in the five generated rules_rs helpers. Restore Cargo dependency discovery for src and tests, retaining the build script dependency needed with Bazel-supplied protoc. Document Bazel 8 or higher and the temporary root-module patch override required by consumers. Apply the same override in the consumer workflow.
The Windows jobs (Run example, release-artifacts) failed during analysis because windows_support's msvc_runtime repository only fetches when BAZEL_MSVC_RUNTIME_VISUAL_STUDIO_EULA is one of 1/yes/y/true. The workflows read it from repository variables, but none are set on Tinder/bazel-diff, so the value was empty. Set both variables to 1 inline, as hermetic-llvm's own CI does. Local Windows builds still have to opt in themselves; the README explains how. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
tinder-maxwellelliott
marked this pull request as ready for review
October 5, 2026 16:37
# Conflicts: # cargo-bazel-lock.json
On windows-latest, analysis of //:bazel-diff failed with a dependency cycle: the MSVC toolchain's SDK case overlays are built by @llvm//tools/case_insensitive_vfs, a C tool compiled for the exec platform. With --host_platform=//platforms:windows_msvc (the setup rules_rs documents), that tool needs the same MSVC toolchain, which needs the overlays again. llvm 0.8.20 added MSVC support and these overlays together, so an older pin is not an option. Apply the fix proposed in hermeticbuild/hermetic-llvm#809: toolchains whose exec OS is Windows leave the overlays out, since Windows file systems are case-insensitive. Linux and macOS toolchains are unchanged. Document the same override for consumers building on Windows. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
# Conflicts: # MODULE.bazel
llvm 0.8.20+ adds hermetic Windows MSVC toolchains. With the MSVC exec platform that rules_rs documents (//platforms:windows_msvc), they first hit an analysis cycle through the SDK case overlays (rules_rs#271, hermetic-llvm#809), and with that patched, the exec-side libc++ build could not find the UCRT headers. hermetic-llvm's own CI only tests a MinGW exec host on Windows. Pin llvm 0.8.19, the workaround reported in rules_rs#271. It has no MSVC toolchains, so Windows builds fall back to Bazel's auto-detected Visual Studio toolchain, as master does today. Linux and macOS stay hermetic: LLVM 22.1.8, the musl release cross-builds, coverage and the MSRV check are unchanged. Drop the hermetic-llvm#809 patch and the MSVC/Windows SDK EULA variables and docs; 0.8.19 does not depend on windows_support. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
With the local MSVC toolchain, the Windows example build failed linking rules_rust's process_wrapper with LNK1181: link.exe could not open ...\rules_rs++toolchains+bazel_diff_rust_toolchains\rustc\default_windows_x86_64_1_90_0_rust_toolchain_bootstrap\lib\rustlib\x86_64-pc-windows-msvc\lib\libstd-*.rlib, a 265-character path, over the 260-character MAX_PATH limit (rules_rs#270). Rename the toolchain and crate repos to bd_rust, bd_msrv, and bd_crates. This shortens that path to 246 characters and all crate paths by 8. The bd_ prefix keeps the names distinct from a consumer's own rules_rs repos, since the extensions share one namespace across modules. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The Windows example build still failed with LNK1181: link.exe could not open ...\rustlib\x86_64-pc-windows-msvc\lib\librustc_std_workspace_alloc-*.rlib, whose full path was 268 characters. - .bazelrc: on Windows, name output directories "win-..." instead of "x64_windows-..." via --experimental_platform_in_output_dir and an override name for //platforms:windows_msvc (8 characters). - CI: start Bazel with --output_base=C:/b instead of --output_user_root=C:/b, which drops the output-base hash directory (9 characters). That path is now 251 characters. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Replace direct
rules_rustandtoolchains_muslconfiguration withrules_rsandllvm. Resolve crates fromCargo.lockand use the built-in musl platforms for static Linux amd64 and arm64 releases. Remove the custom libc constraints, musl toolchain repositories, andcargo-bazel-lock.json; retain the Alpine stress workflows.Keep
all_crate_depsinsrc/BUILDandtests/BUILDwith a five-linerules_rspatch distinguishingpackage_name = Nonefrom"". Document and test the same temporary override for consumers, because Bazel ignores dependency modules' overrides. A BCR release still requires arules_rsrelease containing the fix.Simplify
.bazelrc, release checks, and workflow comments. Test Bazel 8.x and 9.x in the BCR matrices and document Bazel 8 or higher. LLVM 22.1.8 preserves Rust 1.90 coverage support. Windows MSVC/SDK license acceptance comes from repository variables; Windows builds remain unvalidated locally.Validation: 13 native test targets, Rust coverage thresholds, Rust 1.85 build,
cargo check --locked --tests, packed-archive consumer build with the temporary override, Bazel 9.2 analysis, and both Linux musl release cross-builds with static ELF checks.-zbarskybot