You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
CI: the LLVM toolchain job reports success while mcpp's self-build with llvm@20.1.7 fails #729
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 step fails on the build's own exit status (set -o pipefail, or no pipe).
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.
check_function_sizes.sh runs after that step, with xim:llvm-tools at the same version.
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.
Activity
review: the function-size gate is run by hand until CI builds mcpp wi…
2026.9.28.1: eight reports (#717, #718, #720, #722-#726), one downloa…
speak-agent commentedon Sep 28, 2026
Fixed in 2026.9.28.2 (#730), WS7 of the 2026-09-28 ecosystem design.
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.pychecks every workflow for three shapes: a build piped into another command withoutpipefail(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: inci-linux.ymlthis step, the musl-gcc and the GCC cold-rebuild steps and two example steps, and inci-fresh-install.ymltwo template steps (Linux and macOS); after the change it reports none. Its fixture tests run in the Linux static checks.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.docs: the 2026-09-28 round's implementation record, readings and self…
2026.9.28.2: one resolver for the runtime beside a Windows program, h…