汇总:2026-09-20 全量 open issue 核验 —— 关闭十条、三条实测仍复现、其余逐条读数 #677

A full pass over the 44 open issues, each checked against the code that is on origin/main today rather than against what an issue or a release note says about itself. Baseline: origin/main at 05d03cd, released version 2026.9.18.3, measured 2026-09-20. Ten issues are closed by this pass; the rest are classified below with the reading that keeps each one open.

A. Closed in this pass

Each was closed with the evidence in its own thread; the column here is the shortest true reason.

B. Three defects that still reproduce, re-measured today

These are #397's section B, opened 2026-08-09. Four of its nine are now fixed (C-2, C-5, C-6, C-7, C-8 — see the status comment); three still reproduce on 2026.9.18.3 and were measured rather than read.

B1. A fast-path hit never rebuilds compile_commands.json (#397 C-1).

$ mcpp new cdbdemo && cd cdbdemo && mcpp build   # CDB written
$ rm compile_commands.json && mcpp build
    Finished dev in 0.00s
$ ls compile_commands.json
ls: cannot access 'compile_commands.json': No such file or directory

write_compile_commands still has one call site, inside NinjaBackend::build() (src/build/ninja_backend.cppm:3067), which the fast path does not enter. The gate in try_fast_build / try_fast_run has gained inputs since — the SubOS manifest's mtime, dependency source roots, the validated-artifact snapshot — and every one of them is an input. The class named in 2026-08 is still open: fresh inputs do not imply complete outputs. It is reachable from git clean -fd, because mcpp new's .gitignore covers target/ and .mcpp/ but not the CDB.

B2. --no-color is a no-op on a TTY (#397 C-3).

$ script -qec "mcpp build --no-color" /dev/null | cat -v | grep -c '\^\['   # 1
$ script -qec "mcpp build"            /dev/null | cat -v | grep -c '\^\['   # 1

disable_color() (src/ui.cppm:239) clears g_color but not g_inited, so the first output call's init() recomputes from detect_color(), which answers is_tty(). MCPP_NO_COLOR and NO_COLOR are unaffected: they are read inside detect_color(). The reason this survived two years of CI is structural — every e2e captures through a pipe, where detect_color() returns false anyway, so the result is right and the cause is not, and no assertion can tell the two apart. A criterion for the fix has to call ui:: directly.

B3. [modules].exports validation is a silent no-op for any namespaced package (#397 C-4).

src/modgraph/validate.cppm:98 compares u.packageName == manifest.package.name, while src/modgraph/scanner.cppm:1207-1210 fills u.packageName with the qualified name (namespace + "." + name) and :1273 / :1320 are its only writers. With namespace = "acme", actual is the empty set, so neither the ordinary check nor strict ever fires. The comment at scanner.cppm:1204 still explains the qualification by a "module must be prefixed by the package name" check that was deleted in 0b8b81b, leaving :98 dangling.

C. Verified as still open, unchanged

Each of these was checked against the current code; none is fixed, and the reading is given so the next pass need not repeat it.

D. Not defects, and not to be closed as such

• Upstream, tracked deliberately: clang 23.1.0: MSVC STL std module fails with reference to 'align_val_t' is ambiguous (fixed in 23.1.1, llvm/llvm-project#218152) #640 (clang 23.1.0, fixed upstream in 23.1.1), clang 22: a builtin first looked up in a module partition's purview becomes module-owned; importing it beside a GMF use is 'ambiguous' (macOS assert / __builtin_expect) #632 (clang 22 builtin ownership in a partition's purview), clang 22: full BMI from --precompile poisons importers; -c <reduced>.pcm silently emits an object with no definitions #424 and clang 20/22 module BMI: replacement-operator templates with params not pinned by arg1 poison name lookup for all importers (frontend SIGSEGV; gcc + clang18 fine) #256 (clang BMI), ci-macos xcode-27: ld64.lld cannot parse arm64e.x1 in either available SDK (upstream, tracked) #669 (ld64.lld and arm64e.x1 on the xcode-27 image), cppfly: add Clang reflection row when upstream lands P2996 #215 (waiting on P2996). Each exists so the next person who hits the signature finds the mechanism instead of re-deriving it; none should be closed while the signature is still reachable.
• Recent, unresolved: [c-abi] Windows + presents=posix: __unix__ is defined but compat.* still fails (18 packages); engine vs. upstream code assumption #674, GCC self-host: internal compiler error importing mcpp.targetside from a new consumer, under parallel build #667, Clang-built mcpp SIGSEGVs in ELF runtime inspection (validate_changed_artifacts); GCC-built does not #666 — all filed within the last three days, all with live reproductions.
• Standing records: NULL (保留) #43 (reserved), 留言版 | 使用mcpp工具构建的项目(库/工具/应用) #260 (the project board), bench - 构建性能测试 #428 (benchmark data collection), 问题备注 #611 and 备忘:2026-09-04 生态批次之后仍未闭合的四条(armv7a 无 C 库/板级包、riscv32 无后端、ninja 空转未定因、armv7a 无 preemption) #558 (memoranda that exist so their items do not live only in design documents).
• Requirements with an answer but no implementation: feat/RFC: [system_deps] —— 经 pkg-config 集成宿主系统库 #493 (declined as an engine feature, directed to a mcpp.build.pkgconf plugin — the plugin documentation it was waiting on now exists as docs/30-build-mcpp.md and docs/31-authoring-a-rule-package.md), feat: mcpp doc — 集成 doxygen + 用模块图修复跨模块引用 (cargo doc 式注释转文档) #399 (mcpp doc), xpkg Lua 描述符的 mcpp 构建规则无法按版本区分 #290, feat/RFC: 支持 Buildroot/OpenWrt/Yocto 等嵌入式 Linux SDK 的工程化集成 #276.

E. What this pass is not

It reads the code on origin/main and, where a reading was cheap to convert into a measurement, it runs the command instead. It does not re-verify the ecosystem repositories, and it does not re-run any CI. Where an issue's subject is a Windows or macOS host, the reading is from source only — the three defects in section B were each reproduced on Linux x86_64 with the released 2026.9.18.3 binary.