2026.10.8.1: LLVM 23.1.3 line, native Linux ARM64, the 32-bit MSVC coroutine note and no host system headers

[Sunrisepeak]

Moves the LLVM line to 23.1.3, makes native Linux aarch64 select LLVM 23.1.3
with the GNU target, and closes the review findings of Part 3.

LLVM line and defaults

• kKnownTargets' llvm rows, the macOS and Windows-with-MSVC first-run
  defaults and the self-hosting manifest move to llvm@23.1.3 (the first
  release with the macOS 27 arm64e.x1 linker fix). Linux x86_64 keeps
  gcc@16.1.0. Existing user declarations and the musl rows are unchanged.
• Native Linux aarch64 defaults to llvm@23.1.3 on the managed glibc;
  aarch64-linux-gnu is preview until the released engine is consumed on a
  clean ARM64 host. xlings is pinned to 2026.10.8.1.
• A declared toolchain for a graph-supplied target is installed even when no
  payload here serves the target; an engine-chosen one still releases the
  held diagnosis (openkal cross-build macos leg: x86_64-linux-gnu refused although openkal-linux@0.16.1 is in the graph (graph-supply release not firing) #782).
• AArch64 std modules and programs share compiler-rt settings; a
  self-contained ELF that embeds libunwind.a links with --unwindlib=none.

Part 3

• clang 23 does not predefine __cpp_impl_coroutine for i686-pc-windows-msvc.
  mcpp follows the compiler and appends a note to the two failures that
  follow (the C++23 std module inside , and code that uses
  coroutines): C++20 first, llvm@22.1.8 for that target as an option. The std
  module case is decided from its command; the ninja and fast paths from the
  output. Measured on probe PR [temp][do not merge] probe: i686-windows-msvc import std under LLVM 23.1.3 (#781 part 3, G1/G2) #788; e2e 892.
• No host system header directory is searched on a managed C library: clang
  carries -nostdlibinc, GCC without a usable subos takes -isysroot . A project that needs a host header writes -idirafter (e2e 891).
• The graph C library note fires only when the C library is the graph's, on
  the plan path and the fast path (.mcpp-graph-c-library).

Tests and documents

• tests/e2e/_toolchain_env.sh is the one place an e2e learns a toolchain
  version; the four-host target matrix (244 rows) is declared; ARM64 native
  admission, openkal cross and hosted-thread checks run in CI.
• docs/20 and docs/21 (en/zh), READMEs, SPEC-006 v0.7 (§3.8), SPEC-009 v0.6
  (§6.4), CHANGELOG.

Closes #780
Closes #783
Refs: #784, #786

[Sunrisepeak]

CI status notes on the two red legs (both diagnosed, neither is the line move failing its own gate):

1. openkal / build 3 targets on macos — pre-existing main regression, filed as openkal cross-build macos leg: x86_64-linux-gnu refused although openkal-linux@0.16.1 is in the graph (graph-supply release not firing) #782. The same-source example pins its own [toolchain] default = "llvm@22.1.8", the refusal path (host_can_serve + the unserved-target diagnosis) is untouched by this PR, and the openkal job has not run on main since the 2026-10-02 CI acceleration (path-gated: run 37401792942 skipped it). This PR is simply the first tree to exercise the leg in three weeks. The failure fires at the early host-serve gate for x86_64-linux-gnu on a macOS host although openkal-linux@0.16.1 is in the graph — the graph-supply release is not firing.

2. macos / xcode-27 integration leg — ci-macos xcode-27: ld64.lld cannot parse arm64e.x1 in either available SDK (upstream, tracked) #669's failure is gone: mcpp itself built with 23.1.3 on the macOS 27 image and the leg reached the final integration step, which clones openxlings/xlings and builds it. That build resolves xlings' OWN manifest pin macos = "llvm@20.1.7" — 20.1.7's ld64.lld has the same arm64e.x1 TAPI defect — and fails with the old signature on a foreign repository's pin. The cross-repo fix is build: move the macOS self-host pin to llvm@23.1.3 openxlings/xlings#645 (macos pin → 23.1.3, windows deliberately unchanged); once it merges, this leg is expected green and ci-macos xcode-27: ld64.lld cannot parse arm64e.x1 in either available SDK (upstream, tracked) #669 closes.

[Sunrisepeak]

Pushed the second段 of work, three parts:

1. #782 repair. The openkal leg's rerun failure was the decisive sample: llvm@23.1.3 installed successfully (the log shows the autoInstall completing and resolving) and the same refusal still fired — proving the skip was not the only overreach; the whole path treated "diagnosis held" as "unbuildable". The repair: the toolchain resolution always attempts the install now (a declared or --target toolchain is wanted exactly when the graph supplies the target's system); when the install itself fails and the diagnosis stands, it releases there, keeping one cause per message. The openkal leg of this CI run is the fix's verification.

2. e2e toolchain-version abstraction. tests/e2e/_toolchain_env.sh is now the one place a test learns a toolchain version (override env → newest installed payload → fallback constant, per family: llvm/gcc/musl-gcc/mingw-cross). The llvm family's ~90 literals across 38 scripts read it; the next line move edits one file here. _llvm_env.sh stays as an alias shim.

3. #669 closed: xlings#645 merged, both xcode-27 legs green on rerun — the issue's own two closure conditions, both met.

Also answered on the thread: llvm@latest is not accepted today (measured: it is treated as a literal version directory). The engine pins exact releases by design (SPEC-006 §2.1, SPEC-009 §3.4 — reproducible builds). The "track newest" convenience is feasible as parse-layer sugar (translate to the family's newest installed/indexed version, state the translation, keep the exact version in the cache key) — filed as a follow-up decision, not in this PR.

[Sunrisepeak]

Round-3 fixes for the two target-matrix legs the previous push red'd, plus the origin-aware form of the #782 repair:

#782 repair, refined by its own CI. The unconditional install fired on a case it should not: linux-aarch64's restored sandbox cache holds an x86_64-only gcc@16.1.0, so an engine-chosen musl/gnu spec could extract a foreign-arch payload and die later at the hermetic check (297's hosted control on that leg). The install now distinguishes who chose the toolchain: a user-declared toolchain (manifest [toolchain], --toolchain, MCPP_TOOLCHAIN) still installs through the held diagnosis — the declaration outranks the payload matrix, same standing as the [target.X] toolchain escape hatch; an engine-chosen one (row pin, host default) skips when the target is unservable, releasing the held diagnosis with its correct sentence. This is the rule the SPEC-009 §11 distinction (recorded default vs user declaration) implies for installs.

297's gate now asks the resolver, not the file listing. The matrix contract on non-linux-x86_64 hosts is a skip naming the FACT ("gcc is not installed here"); the old gate read toolchain list, which a foreign-arch cache leftover satisfies while the toolchain cannot run. The gate now queries why toolchain for the host-arch gnu row — in a directory with a minimal manifest, since from a bare one the query refuses with no mcpp.toml found (reason other) before reaching the resolver. A real gcc resolves (reason: none, the test runs, as on linux-x86_64); a foreign-arch leftover gets host-cannot-serve and the declared skip. Measured locally: linux-x86_64 with a working gcc runs to OK.

[Sunrisepeak]

Round-4 fix, caught by the macos-e2e leg: the heredoc unquoting from the abstraction migration had silently not landed — 14 fixtures still carried <<'EOF' with `` inside, so macOS/Windows read the literal llvm@${LLVM_VERSION} from their generated manifests and died at resolution (234's "build with bmi_schedule=on failed" was this, not a scheduler regression). Re-applied with an absolute-path pass and a re-audit: no `${LLVM_VERSION}` remains inside a quoted heredoc; 234/738/804 re-verified locally with the expansion in place. (881/182 local failures are environment-shaped — 881 is `requires: msvc` Windows-only, 182 times out on this machine's cold index init — both run in CI's own shards.)