[tinder-maxwellelliott]

Why BCR stopped merging at 67.0.1

Registry PRs for 67.0.2, 67.0.3 and 68.0.0 (#11404, #11422, #11451) pass every Bazel 9.x task and fail every 8.x task. The Buildkite log ends with:

Migration is needed for the following flags:
  --incompatible_config_setting_private_default_visibility
bazel build failed with exit code 73
ERROR: BCR presubmit failed with incompatible flags.

BCR rebuilds each verify_targets task once per flag listed in its incompatible_flags.yml (five flags for 8.x, none for 9.x). 67.0.2 (#580) added config_setting(name = "without_mimalloc") in src/BUILD with no visibility, which that flag makes private. Reproduced locally by consuming the v68.0.0 archive with the flag:

target '@@bazel-diff+//src:without_mimalloc' is not visible from
target '@@bazel-diff+//src:bazel-diff'

Separately, 68.0.0's registry PR is still a draft (publish-to-bcr opens drafts; marking it ready triggers the auto-approve) and its pipeline step 404'd on release.tar.gz because the GitHub release was still a draft when Buildkite ran (publish at 13:23, finalize at 13:41). The fix here only reaches BCR with the next release; the three stuck PRs can be bypassed with a @bazel-io skip_check incompatible_flags comment from their author or closed.

Changes

• src/BUILD: without_mimalloc is //visibility:public.
• bcr_consumer.yaml: now mirrors the registry presubmit's incompatible-flags phase. It downloads BCR's incompatible_flags.yml, selects the flags for the matrix Bazel version with the new tools/bcr_incompatible_flags.py (unit tested), and rebuilds the consumer targets once per flag like BCR does, so this class of failure fails here instead of the registry. The matrix also gains windows-latest rows using the presubmit's Windows build_flags, since last month's MAX_PATH stall was a Windows-only presubmit failure nothing here caught. The per-flag rebuilds push the Windows 8.x row to about 40 minutes, so the workflow now runs on master pushes and on demand rather than on every PR; releases are cut from master, so a registry rejection is still caught before the next release, and none of the rows is a required check.
• MODULE.bazel: llvm 0.8.19 → 0.8.26 (hermetic-llvm#853 fixes the Windows exec-host cycle hermetic-llvm#809 / rules_rs#271 that pinned us), rules_rs 0.1.3 → 0.2.0, protobuf 33.4 → 36.2. rules_rs 0.2.0 requires Bazel 8.7+, so bazel_compatibility and the CI minimum-Bazel example row move from 8.5.0 to 8.7.0.
• MODULE.bazel.lock regenerated.

Verification

• bazel test //src/... //tools/... //:rust_clippy_check //:rust_format_check: 16/16 pass.
• Consumer build of the packed release archive on Bazel 8.x with all five BCR incompatible flags: succeeds. The same build of the published v68.0.0 archive fails with the visibility error above.
• Windows with llvm 0.8.26 is only covered by CI here (Run example and release-artifacts Windows jobs).

Windows stays on the locally installed MSVC

llvm 0.8.26's hermetic Windows MSVC toolchain downloads the MSVC runtime and Windows SDK, which refuse without --repo_env=BAZEL_MSVC_RUNTIME_VISUAL_STUDIO_EULA=1 and --repo_env=BAZEL_WINDOWS_SDK_EULA=1 from every Windows builder (both Windows example jobs failed on that). Rather than accept Microsoft's licenses in the repo and require them of Windows consumers, register_toolchains now lists the 16 Linux/macOS exec-to-target toolchains explicitly and leaves the Windows ones unregistered, so Windows keeps using Visual Studio as with llvm 0.8.19. Verified on macOS that the host and the musl Linux release target still resolve to the llvm toolchain.

Windows upgrade note

llvm 0.8.26 raises rules_cc from 0.2.22 to 0.2.25. On Windows (local MSVC), building a pre-bump revision in an output base that a post-bump build has populated fails with an undeclared inclusion of a protobuf _virtual_includes header; each revision builds fine on its own, and Linux is unaffected. The Windows example CI job hit this by rebuilding master after HEAD, so it now builds once at HEAD and passes the binary to the script. A Windows user switching bazel-diff across this bump in one output base needs a bazel clean.

🤖 Generated with Claude Code