fix(scanner, host modules, toolchain, config, bench): five open issues, and three of the reports were wrong about the cause

#606  THE SCANNER READ INSIDE COMMENTS, IN BOTH DIRECTIONS. Block-comment
      state never existed in the file's history -- `git log -S` returns no such
      commit -- so the bisect to "after 2026.9.7.1" dates when the defect
      became audible, not when it was introduced; the refusal added at
      2026.9.9.1 is correct. The unreported form is worse: `export module y;`
      inside a block comment made a plain `.cpp` the recorded producer of
      `y.gcm`, and a real importer of `y` was then told `imports must be built
      before being imported`. And the OTHER direction, also unreported: a
      commented-out raw-string opener blanked every following line, so real
      imports were invisible to the scanner and visible to the compiler -- a
      missing dependency edge, which is a build-order race rather than a
      deterministic refusal.

      One pass over three states. Eight criteria in tests/e2e/639, two of them
      properties that were already correct and must not be lost; six of the
      eight go red against released 2026.9.10.2.

#604  A TWO-TOKEN SWITCH LOST ITS SWITCH. The host-module flag collector
      de-duplicated per token and was written for GCC's one-token `-fmodules`.
      MSVC's reference is a pair whose first half legitimately repeats, so the
      pair lost `/reference` and cl read `<name>=<path>` as a source file
      (C1083). Appended verbatim now; the comment being replaced stated the
      filter's whole value ("harmless but noisy"). Plus
      `orphaned_reference` as a reader that names the cause before the command
      runs.

#603  THE LEVEL IS A PROPERTY OF THE STL. Calling the existing probe from
      clang's path would have compared a clang version against an MSVC
      threshold. The toolset version is in the path of the `std.ixx` already
      selected; one function, both paths, and a test that the two forms agree
      for a well-formed installation.

#564  `default_jobs` gained a reader and `default_backend` was removed. Two
      dead keys wanting opposite answers: one names a machine fact with no
      other home, the other promises a choice that does not exist. The test
      asserts the precedence, not the wiring.

#599  A CHECK THAT HAD RUN IN ZERO CI JOBS. Three defects, not the two
      reported: the hub path was written for the current layout while naming a
      historical tree, the `uninit` branch printed a note that cannot turn a
      job red, and there is no bench workflow at all -- so the test's own
      justification for the note was false. All three fixed, and the note now
      fails under CI while staying a note locally.

Author: speak-agent

.agents/docs/2026-09-11-six-open-issues-analysis.md

@@ -410,3 +410,124 @@ leaving it in place:
 5. **#597** -- graduating a row that already exists, in the batch that added it.
 
 The first four are one release. #597 belongs to the platform batch.
+
+## 8. Self-review, and the one plan a measurement changed
+
+Written after §1-§7 and before any implementation. Four of the six plans
+survive unchanged. One is wrong, one has an unstated cost, and the review
+found the defect the plan for #606 would have half-fixed.
+
+### 8.1 #606: the defect is bidirectional, and the other direction is worse
+
+§1 proposed "a `bool in_block` carried across iterations, with the stripping
+done before `strip_line_comment`", and gave as a criterion that
+`/* */ import x;` on one line "still records the import". Both are wrong.
+
+Measured on 2026.9.10.2, by whether mcpp emits its own
+`imported but not provided` warning (which only the scanner can produce, so it
+separates "the scanner saw it" from "the compiler saw it"):
+
+| source | scanner | correct |
+|---|---|---|
+| `import x;` | sees it | sees it |
+| `const char* s = "a /* b";` then `import x;` | sees it | sees it |
+| `/* */ import x;` | **misses it** | sees it |
+| `// R"(` then `import x;` | **misses it** | sees it |
+| `/*`, `R"(`, `*/` then `import x;` | **misses it** | sees it |
+| `/*`, `export module y;`, `*/` | records a phantom producer | ignores it |
+| `/*`, `module (exe)`, `*/` | refuses the build | ignores it |
+
+So `/* */ import x;` is not a behaviour to preserve -- it is a fourth wrong
+answer. And two of the wrong answers run in the **opposite** direction to the
+reported one: a `//`-commented or block-commented raw-string opener puts
+`strip_raw_strings` into raw mode, which blanks every following line until a
+`)"` that never comes, and real declarations after it are invisible to the
+scanner while remaining visible to the compiler.
+
+A missed `import` is worse in kind than a refused build. It is a **missing
+dependency edge**: the compile is not ordered after the BMI it needs, so the
+failure is a build-order race that appears under parallelism as
+`failed to read compiled module` and disappears on a retry. #606's reported
+form is at least deterministic.
+
+The two directions have one cause. The scanner has three lexical states --
+code, block comment, raw string -- which are mutually exclusive and decided by
+whichever opener comes first. It implements one and a half: raw strings fully,
+line comments as an unconditional `find("//")`, block comments not at all, and
+the three passes run in a fixed order that cannot express "whichever came
+first". Fixing block comments alone, in either order relative to the existing
+passes, produces one of the two wrong directions:
+
+* strip comments first, and `R"( /* )"` opens a comment inside a string;
+* strip raw strings first, and `// R"(` opens a string inside a comment --
+  which is the defect measured above.
+
+### 8.2 The revised plan for #606
+
+One pass over the line with the three states, replacing `strip_raw_strings` and
+`strip_line_comment` at the call site. It blanks non-code and preserves
+offsets, so the reported column stays correct. State carried across lines is
+what it already is (`in_raw`, `raw_close`) plus `in_block`.
+
+Not a lexer: character and string literals need no tokenising, because the only
+question asked of the result is whether the trimmed line *starts with* a
+keyword, and an ordinary `"..."` cannot begin a line with one. The one thing
+the pass must respect about them is `"a /* b"` -- a `/*` inside an ordinary
+string must not open a comment -- which is one state, not a literal parser.
+
+Criteria, one per row of the table above, with the last two being the pair that
+separates a fix from a mute:
+
+* the phantom-producer case generates a graph with no `gcm.cache/y.gcm` output;
+* the four-line file from the report builds;
+* `/* */ import x;` records the import -- a *new* property, and the one that a
+  cheap "skip any line starting with `/*`" would fail;
+* `"a /* b"` then `import x;` still records the import -- currently correct by
+  luck, and the property that stops the fix from treating every `/*` as an
+  opener.
+
+### 8.3 #603: one function, and the two answers must be measured to agree
+
+§3 left open whether the MSVC path keeps the cl banner. It must not: two
+readers of one question is what this codebase treats as the defect, and the
+`std.ixx` path is the better input on both paths, because it describes the STL
+that will actually be compiled rather than the one a fresh search finds first.
+The unit test therefore asserts that for a well-formed VC layout the path
+answer equals what the banner answer would have been -- otherwise the change
+is a silent behaviour change on the one path that was verified.
+
+### 8.4 #599: the cost of running the check is not stated
+
+§4 proposes `submodules: true` on the checkout of whichever shard runs `233`.
+The bench workloads are pinned full source trees of mcpp and xlings, so this is
+not free, and the plan does not say what it costs. Measure before choosing;
+if it is large, the cheaper shape is a job that checks out **only**
+`bench/projects` and runs `233` alone, since the check needs trees and no
+toolchain at all.
+
+### 8.5 #604 and #564 stand, with one narrowing each
+
+#604: append verbatim, and de-duplicate nothing. The alternatives considered --
+de-duplicate by logical module name, or by contiguous subsequence -- are both
+correct and both add a rule to keep an argv tidy. The rule being removed was
+wrong; replacing it with a better rule for the same cosmetic purpose is the
+kind of trade this codebase records as a mistake. The comment says the repeat
+is harmless; the fix should rely on that sentence rather than work around it.
+
+#564: the e2e must assert the *precedence*, not the plumbing. A fixture that
+only sets `default_jobs` and reads `-j3` would pass if the global value were
+wired in above `MCPP_JOBS` instead of below it. Two invocations of one
+fixture, with and without `MCPP_JOBS`, is the smallest thing that distinguishes
+them.
+
+### 8.6 #597 stands, and route A now makes a second row measurable
+
+Unchanged. Noted here because the platform record's Android rows were resolved
+by the same kind of measurement in the same session: `qemu-aarch64 -L <root
+extracted from the system image>` executes the **default, dynamic**
+configuration for `aarch64-linux-android`, with `libc++_shared.so` supplied
+from the NDK's own directory outside the `-L` prefix. The emulator route is
+refuted for every build the vendor manifest currently serves, measured across
+all four Linux host entries rather than the pinned one. So both remaining
+platform rows are executable on an x86_64 Linux runner with no device and no
+virtualization, which is what a CI lane needs.

.github/actions/setup-macos-llvm/action.yml

@@ -107,7 +107,6 @@ runs:
 
         [build]
         default_jobs    = 0
-        default_backend = "ninja"
         EOF
 
         cat "$HOME/.mcpp/config.toml"

.github/workflows/ci-linux-e2e.yml

@@ -42,7 +42,22 @@ jobs:
       # set only in the fresh-install workflows (cold bootstrap, no such asserts).
       # A specific test that needs verbose passes `--verbose` itself.
     steps:
+      # `submodules: recursive` so tests/e2e/233_bench_matrix.sh can check that
+      # each `hub`/`body` in bench/matrix.json exists in the tree it names.
+      # Without the trees that check reads "submodule not initialised" and
+      # reports nothing, which is how a hub path written for the CURRENT
+      # layout stayed in matrix.json while the workload it named is a
+      # HISTORICAL mcpp -- three cells reporting `skipped` on every bench run
+      # and the job still green (#599).
+      #
+      # It is not free and it is not expensive: the three pinned workloads are
+      # 725 + 701 + 806 tracked files, under 10 MB of source in total, and
+      # nothing here builds them. Both shards carry it because run_all.sh
+      # slices the file list round-robin, so which shard holds 233 moves when
+      # a test is added.
       - uses: actions/checkout@v4
+        with:
+          submodules: recursive
 
       # Same cache lineage as ci-linux.yml so this job lands on a warm
       # toolchain/sandbox instead of re-installing it.

CHANGELOG.md

@@ -7,6 +7,112 @@
 
 ## [2026.9.11.2] - 2026-09-11
 
+### 扫描器读到了注释里面,而且是双向的
+
+**报告的那半。** `/*` 单独占一行、下一行是 `module (`,那一行被当成模块声明匹配,
+四行普通 C++ 被拒绝(#606)。报告把它二分到「2026.9.7.1 之后的回归」。实测:
+`git log -S` 在 `src/modgraph/scanner.cppm` 上返回**零个**曾添加块注释状态的提交 ——
+它从来没有过。2026.9.9.1(#594)加的畸形名拒绝是**对的**,二分定位到的是缺陷**变响**
+的时间。
+
+**没被报告、而更坏的那半。** 名字合法时那条拒绝不会触发,结果是:块注释里的
+`export module y;` 让一个普通 `.cpp` 被记录成 `gcm.cache/y.gcm` 的**生产者**,承诺一个
+编译器永不写出的 BMI。真正 `import y;` 的文件于是被告知 `imports must be built
+before being imported` —— 一个并不存在的顺序问题,而真正的提供者从未被查找。
+
+**以及反方向。** `// R"(` 让 raw string 那一遍进入它出不来的状态,把之后每一行都
+抹空到一个永不出现的 `)"`;`import x;` 对扫描器不可见而对编译器可见。**那是一条
+缺失的依赖边** —— 并行下的构建顺序竞争,重试就好,比报告的那条更坏。`/* */ import
+x;` 同样被漏掉,是报告没有提到的第四个错答案。
+
+根因是一段被当成已完成的论证,写在源码注释里:「普通 `"..."` 字符串故意原样保留:
+匹配器只在 trim 后**以关键字开头**的行上触发,而字符串体只有跨行(即 raw string)
+才做得到这件事。」前提成立,枚举少了一个 —— **块注释也能**。
+
+修法是**一遍走三个状态**:代码、块注释、raw string 互斥,由先出现的那个开启符决定,
+这是任何固定顺序的分遍都表达不了的。判据八条(`tests/e2e/639`),其中两条是
+「原本就对、不能弄坏」的:`/* */ import x;` 必须**看见**那个 import(否决「跳过任何
+以 `/*` 开头的行」这种哑修法),`"a /* b"` 必须**不**开启注释。拿已发布的
+2026.9.10.2 对照:八条里六条变红。
+
+### 一个两 token 的开关丢掉了它的开关
+
+`windows = "msvc@system"` 下,一个带 `host-module` 构建依赖的包在编译构建程序时失败:
+
+```
+c1xx: fatal error C1083: Cannot open source file:
+  'huxerui.rules.sources=...\huxerui.rules.sources.ifc'
+```
+
+`cl.exe` 把模块引用读成了**源文件名**。成因是 host-module 的 flag 收集**按 token**
+去重,而它是为唯一一个「单 token 且幂等」的家族写的 —— GCC 的 `-fmodules`:
+
+| 家族 | useFlags | token |
+|---|---|---|
+| GCC | `-fmodules` | 1,幂等 |
+| Clang | `-fmodule-file=<name>=<path>` | 1,唯一 |
+| MSVC | `/reference`, `<name>=<path>` | **2,第一个合法重复** |
+
+内层 host module 追加时,`/reference` 已由内置 `mcpp` 模块放进列表 → 被跳过,只追加
+了对的后半。Clang 按构造免疫(一个词,永不等于已有元素),所以缺陷专属于那唯一一个
+在 Windows 上能在 c++20 达到 `import std;` 的工具链选择(#604)。
+
+**逐字追加,不再去重。** 被替换的那句注释说明了这个过滤器的全部价值:「repeating it
+is harmless but noisy」—— 它买的是 argv 整洁,付的是坏命令行。按逻辑模块名去重、
+或按连续子序列去重,两者都正确,而两者都是为同一个装饰性目的**新增一条规则**。规则
+被删掉了。
+
+另加 `mcpp::toolchain::orphaned_reference`:一个 `<name>=<path>` 前面没有开关时,
+在命令跑之前拒绝并说明,而不是从 cl 的 C1083 里去反推。这是纵深防御而不是修复本身。
+
+### `import std;` 的档位问的是 STL,不是碰巧到达它的那个编译器
+
+clang 在 Windows 上回落到 MSVC STL 的 `std.ixx` 时把 `importStdMinLevel` 硬编码成
+23,于是一个 c++20 工程在 Windows 上被拒绝,而同样的源码在 Linux 的 GCC 16.1、
+Linux 的 llvm 22.1.8 和 macOS 上都能构建(#603)。
+
+那段注释把理由说对了 ——「`tc.version` 是 clang 的,所以它回答不了 cl banner 的问
+题」—— 却从中得出了错的结论。**照原样调用已有探针会更坏**:那会拿一个 clang 的版本号
+去和 MSVC 的 19.38 门槛比,clang 20.x 侥幸通过、clang 19.x 错误地答 23,两个答案都
+来自问错对象。
+
+真正有约束力的版本在**刚刚选中的那个模块源文件的路径里** ——
+`<VS>/VC/Tools/MSVC/14.44.35207/modules/std.ixx` —— 而 toolset `14.<N>` 与 cl banner
+`19.<N>` 配对,所以现有的 `>= 38` 谓词原样迁移。新增
+`std_module_min_level_for_stl(path)`,**两条路径都调它**;单测断言对一个规整的安装,
+两种形态给出相同答案 —— 否则这次改动就是对唯一被验证过的那条路径的静默行为变更。
+
+### `[build] default_jobs` 有了读者,`default_backend` 被删掉
+
+两个键都被解析、都没有任何消费者(#564)。它们要的是**相反**的答案。
+
+`default_jobs` 接上:它是三级优先级里唯一能承载**机器事实**的一级
+(`MCPP_JOBS` > `[build] jobs` > `default_jobs` > 0)。`--jobs` 每次调用都要重说,
+`[build] jobs` 是按包的而 `[workspace.build]` 正确地拒绝它,所以别无他处。它以
+**参数**而不是 config import 的形式到达 `resolve_jobs`,因为那个函数刻意只依赖
+manifest 和宿主。它**同时**约束 `mcpp test` 的并发,这一点被明写进文档 —— 一个键
+两种行为必须明说。单测断言的是**顺序**而不是接线:只设全局值再读回来的夹具,在参数
+被接到 `MCPP_JOBS` **之上**时同样会通过。
+
+`default_backend` 删掉:`BackendKind` 有两个值而 `src/build/` 只有一个后端实现,
+这个键承诺了一个不存在的选择,而默认值 `"ninja"` 让它看起来是实现了的。四个 e2e
+夹具和一个 CI action 各自持有一份生成文件的副本,都同步了。
+
+### bench 的 hub 检查从写下起在 CI 里跑过零次
+
+`matrix.json` 给 mcpp 工作负载写的 hub 是 `modules/platform/src/platform.cppm`,而那个
+工作负载是一个**历史** mcpp,该文件在其中位于 `src/platform/platform.cppm`(#599)。
+三个 cell 的每一个扰动场景都会报 `skipped` 而 job 照常绿。
+
+报告发现两个缺陷,实际有三个,而第三个吞掉了前两个:**`.github/workflows/` 里没有
+bench workflow**,也没有任何 job 检出 submodule。所以 233 自己那句理由 ——「bench
+workflow 会检出 submodule 并跑这个测试」—— 是假的。
+
+三处都修:hub 路径按 pin 重读(并在 `matrix.json` 里记下「hub/body 属于 pin 而不属于
+本仓库」),`uninit` 分支在 `CI=true` 下**失败**而在本地打印提示(两类读者的答案相反),
+以及 `ci-linux-e2e.yml` 的两个 shard 都带上 `submodules: recursive` —— 三个 pin 合计
+2232 个 tracked 文件、不到 10 MB 源码,而且这里什么都不构建。
+
 ### 暂存对被分派的格式是**服务**,不是前置条件
 
 `mcpp pack --format <name>` 在分派之前无条件先暂存一次,而暂存失败就让整条命令失

bench/matrix.json

@@ -1,11 +1,23 @@
 {
   "schema": 2,
   "_comment": [
-    "THE benchmark matrix. Read by .github/workflows/bench.yml to plan its jobs and",
-    "by tests/e2e/233_bench_matrix.sh to check this file against the harness's own",
-    "vocabulary. bench/SPEC.md explains the axes; it deliberately does not repeat",
-    "the cell list, because a matrix written down twice is a matrix that disagrees",
-    "with itself.",
+    "THE benchmark matrix. Read by tests/e2e/233_bench_matrix.sh, which checks it",
+    "against the harness's own vocabulary and against the pinned trees. bench/SPEC.md",
+    "explains the axes; it deliberately does not repeat the cell list, because a",
+    "matrix written down twice is a matrix that disagrees with itself.",
+    "",
+    "THERE IS NO .github/workflows/bench.yml IN THIS REPOSITORY. This comment used",
+    "to name one, and so did 233's own justification for printing a note instead of",
+    "failing -- which is why the hub/body existence check ran in zero CI jobs from",
+    "the day it was written, and why the three mcpp cells below carried a path from",
+    "the CURRENT source layout while naming a HISTORICAL tree (#599). 233 now runs",
+    "with the submodules checked out in ci-linux-e2e.yml and fails rather than notes",
+    "when they are absent on a runner. Running the benchmark itself is still manual.",
+    "",
+    "A `hub` OR `body` PATH BELONGS TO THE PIN, NOT TO THIS REPOSITORY. Each",
+    "workload is a historical commit, so a path that is correct in the current tree",
+    "is wrong for it by construction and the next module move breaks it again. When",
+    "a pin is bumped, re-read these two paths out of the new tree.",
     "",
     "A cell is one CI job. Inside it the harness sweeps every engine x variant x",
     "scenario, so those axes are per-cell lists rather than more jobs: they share a",
@@ -133,7 +145,7 @@
       "engines": "mcpp,mcpp[schedule=on],cmake,xmake",
       "variants": "modules",
       "scenarios": "cold,noop,touch-hub,edit-body,edit-comment",
-      "hub": "modules/platform/src/platform.cppm",
+      "hub": "src/platform/platform.cppm",
       "body": "src/version_req.cppm",
       "note": "KNOWN GAP: cmake cannot GENERATE this project on the runner. It configures (the compiler probe passes) and then fails with `CMake Error: the \"CXX_MODULE_STD\" property ... requires that the \"__CMAKE::CXX23\" target exist, but it was not provided by the toolchain. Reason: Only `libstdc++` is supported`. Everything checkable from outside has been checked and every one of them AGREES with a developer box where the same arm configures, generates and builds: same cmake (the very same `xim-x-cmake/4.0.2` xlings payload, not merely the same version), same `xim-x-gcc/16.1.0`, `libstdc++.modules.json` present on the runner, both sources it names (`std.cc`, `std.compat.cc`) present on the runner, and the runner's exact flag shape (`-B<glibc>/lib -L<glibc>/lib`, the branch this machine does not normally take) reproduced locally via a fake MCPP_HOME with no subos — it works there. What is left is inside CMake's own detection. The arm's CMakeConfigureLog is now attached to the cell log on failure so the next look starts from CMake's own record rather than another hypothesis. BASELINE MOVED to the released mcpp for this cell, exactly as the xlings cells do: normalising against an engine that never produced a binary prints bare seconds under a heading that says `relative to`. xmake and both mcpp arms stay measured here. The published cmake numbers in bench/README were taken on a machine where this arm works.",
       "buildfiles": "mcpp",
@@ -147,7 +159,7 @@
       "engines": "mcpp,mcpp[schedule=on],cmake,xmake",
       "variants": "modules",
       "scenarios": "cold,noop,touch-hub,edit-body,edit-comment",
-      "hub": "modules/platform/src/platform.cppm",
+      "hub": "src/platform/platform.cppm",
       "body": "src/version_req.cppm",
       "buildfiles": "mcpp",
       "allow_failed": "xmake",
@@ -160,7 +172,7 @@
       "engines": "mcpp,mcpp[schedule=on],cmake,xmake",
       "variants": "modules",
       "scenarios": "cold,noop,touch-hub,edit-body,edit-comment",
-      "hub": "modules/platform/src/platform.cppm",
+      "hub": "src/platform/platform.cppm",
       "body": "src/version_req.cppm",
       "buildfiles": "mcpp",
       "allow_failed": "cmake,xmake",