build(deps): replace toolchains_llvm with hermetic-llvm 0.8.19

.bazelrc

@@ -18,21 +18,18 @@ test --test_output=errors
 # Hermetic LLVM toolchain with libc++ (dev-only; see MODULE.bazel): the linux
 # clang+libc++ matrix cell. libc++-only divergences — vector<bool>'s proxy
 # std::hash (#84), C++20-removed traits like std::result_of — otherwise
-# surface only on the macOS runners or in consumers' toolchains_llvm builds.
-build:llvm --extra_toolchains=@llvm_toolchain//:all
-# toolchains_llvm 1.8's builtin-libc++ mode pairs -stdlib=libc++ with explicit
-# libc++ system-include paths, so clang reports the flag unused on every
-# compile — driver noise from the toolchain's own flag set, which
-# --config=werror would otherwise promote to an error.
-build:llvm --copt=-Wno-unused-command-line-argument
-# boost.context's BCR BUILD opts itself into parse_headers, and 1.8 is the
-# first toolchains_llvm that registers the tool for it — so its headers now
-# compile standalone, where the pre-C++17 std::result_of polyfill meets
-# C++20 libc++ (which removed the trait) and fails hard. Its own actions
-# compile as C++17 (this trailing per-file flag outranks the global
-# -std=c++20); every first-party TU stays C++20, and the other legs never
-# parse external headers (libstdc++ keeps the trait; Apple's toolchain has
-# no parse_headers tool).
+# surface only on the macOS runners or in consumers' hermetic-LLVM builds.
+# The toolchains stay unregistered in MODULE.bazel and are selected here, so
+# an ordinary build keeps the autodetected host toolchain.
+build:llvm --extra_toolchains=@llvm//toolchain:all
+# boost.context's BCR BUILD opts itself into parse_headers, and this toolchain
+# registers the tool for it — so its headers compile standalone, where the
+# pre-C++17 std::result_of polyfill meets C++20 libc++ (which removed the
+# trait) and fails hard. Its own actions compile as C++17 (this trailing
+# per-file flag outranks both the toolchain's own default -std=c++17 and the
+# global -std=c++20 that overrides it); every first-party TU stays C++20, and
+# the other legs never parse external headers (libstdc++ keeps the trait;
+# Apple's toolchain has no parse_headers tool).
 build:llvm --per_file_copt=external/boost.context@-std=c++17
 
 # AddressSanitizer: bazel test //... --config=asan

.github/workflows/ci.yml

@@ -29,7 +29,7 @@ jobs:
             os: ubuntu-24.04
             cc: clang
             cxx: clang++
-          # Hermetic toolchains_llvm with libc++: the only linux libc++ cell,
+          # Hermetic zero-sysroot LLVM with libc++: the only linux libc++ cell,
           # and the toolchain serious Bazel consumers run (its parse_headers
           # validation of our REPO.bazel-shipped feature included).
           - name: linux-llvm-libcxx

MODULE.bazel

@@ -29,18 +29,16 @@ bazel_dep(name = "rules_testing", version = "0.9.0", dev_dependency = True)
 
 # Hermetic LLVM toolchain with libc++ — the linux clang+libc++ matrix cell
 # (CI's --config=llvm job) and the setup serious Bazel consumers run
-# (toolchains_llvm + parse_headers is exactly the environment that caught the
+# (a hermetic clang + parse_headers is exactly the environment that caught the
 # boost.context std::result_of gap). Dev-only and unregistered by default:
 # the CI job selects it with --extra_toolchains, so ordinary builds keep the
-# autodetected toolchain. libc++ is toolchains_llvm's default stdlib.
-bazel_dep(name = "toolchains_llvm", version = "1.9.0", dev_dependency = True)
-
-llvm = use_extension("@toolchains_llvm//toolchain/extensions:llvm.bzl", "llvm", dev_dependency = True)
-llvm.toolchain(
-    name = "llvm_toolchain",
-    llvm_version = "19.1.7",
-)
-use_repo(llvm, "llvm_toolchain")
+# autodetected toolchain. libc++ is this toolchain's default stdlib.
+#
+# hermetic-llvm (BCR module "llvm") rather than toolchains_llvm: it is
+# zero-sysroot, so the cell compiles against Bazel-supplied glibc/kernel
+# headers and libc++ instead of the runner's /usr/include, and the LLVM
+# version rides the module rather than a pinned release tarball.
+bazel_dep(name = "llvm", version = "0.8.19", dev_dependency = True)
 
 # The code generator runs inside the build graph as a hermetic Java action
 # (bazel/defs.bzl); rules_jvm_external pins its Smithy dependencies.