Skip to content

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

Description

@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

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.

Activity

  1. added a commit that references this issue on Sep 27, 2026
  2. speak-agent commented on Sep 28, 2026

    @speak-agent
    MemberAuthor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions