CI: the LLVM toolchain job reports success while mcpp's self-build with llvm@20.1.7 fails

[speak-agent]

The toolchain: musl + llvm job in .github/workflows/ci-linux.yml reports success while its mcpp self-build with llvm@20.1.7 fails.

Observation

On main (run 36308923378, commit b439fd9), the step "Toolchain: LLVM — build mcpp" logs error: build failed and two failed edges:

FAILED: obj/xlings.m.o
FAILED: pcm.cache/mcpp.xlings.pcm

The step is "$MCPP" build 2>&1 | tee build.log; grep -q "Resolved llvm@20.1.7" build.log. The pipeline's status is grep's, so the step asserts only that the toolchain was resolved, never that the build succeeded. The same holds on the 2026.9.28.1 branch (#727).

Cause of the build failure

Under import std; with libc++ 20, a range-based for over std::filesystem::directory_iterator (or recursive_directory_iterator) fails: the iterator's comparison with another iterator is not visible through the module, and only the default_sentinel_t overloads are found.

src/xlings/xlings.cppm:1006:24: error: invalid operands to binary expression ('directory_iterator' and 'directory_iterator')
modules/buildmcpp/src/tool_store.cppm:215:15: error: invalid operands to binary expression ('fs::recursive_directory_iterator' and 'fs::recursive_directory_iterator')

The same sources build with llvm@22.1.8.

Consequences

• No CI job builds mcpp itself with clang on Linux, although the job's name says one does.
• The function-size gate of prepare: split the longest phase functions into sub-steps #722 (.github/tools/check_function_sizes.sh, clang-tidy readability-function-size) needs a compile database from a successful clang build. It was wired after this step on 2026.9.28.1: eight reports (#717, #718, #720, #722-#726), one download progress, and an index floor that is a tip #727, crashed over the partial database, and was taken out again; it is run by hand until this is resolved.

Proposed

1. The step fails on the build's own exit status (set -o pipefail, or no pipe).
2. The step builds with the LLVM row mcpp documents as its own development toolchain (22.1.8), or mcpp's module units avoid the construct libc++ 20 cannot compile; the first is the smaller change.
3. check_function_sizes.sh runs after that step, with xim:llvm-tools at the same version.

[speak-agent]

Fixed in 2026.9.28.2 (#730), WS7 of the 2026-09-28 ecosystem design.

• The LLVM self-build step runs under set -o pipefail, so the build itself is asserted, not only the resolution line, and it builds with llvm@22.1.8; the function-size gate of prepare: split the longest phase functions into sub-steps #722 (check_function_sizes.sh) runs after it and reads that build's compile database.
• .github/tools/check_workflow_assertions.py checks every workflow for three shapes: a build piped into another command without pipefail (W1), an exit status that is discarded (W2), and a job allowed to fail without naming its issue (W3). On the workflows before the change it reported 7 problems, all W1: in ci-linux.yml this step, the musl-gcc and the GCC cold-rebuild steps and two example steps, and in ci-fresh-install.yml two template steps (Linux and macOS); after the change it reports none. Its fixture tests run in the Linux static checks.
• The xcode-27 legs are marked known red with ci-macos xcode-27: ld64.lld cannot parse arm64e.x1 in either available SDK (upstream, tracked) #669 and continue-on-error.

Reading: every workflow run on the merged head concluded success; the self-build and the size gate ran green in ci-linux.