Windows: 进程 ACP 之外的路径,mcpp 只能跳过而不能构建 #518

从 #516 的收敛工作里分出来的两件事,都不是那次修复的范围,但都还开着。

#516 修的是「一个当前代码页拼不出的目录名不该终结整个构建」。修完之后的行为是:
这类文件被跳过,并按目录报告一次。这对 cpp-httplib 那种「测试数据里有个日文目录」
是正确的答案 —— 但它不是「支持这些路径」。下面两件事才是。

A. 项目根目录含非 ACP 字符时,构建以「没有源文件」失败

不是崩溃 —— path_matches_glob 会把每一个候选判为不匹配(它们的相对路径含
拼不出的前缀),于是 glob 一个文件都收不到,构建报的是「没有源文件」。

对用户而言这是指错方向的诊断:真正的原因是项目路径,而错误说的是 sources。
典型场景是英文版 Windows(ACP=1252)+ 中文项目路径 —— 在国内不罕见。

最小改进(与 B 独立):当一次 glob 走查里,被跳过的条目数 ≥ 命中数、且跳过的
锚点就是项目根本身时,把诊断从「没有源文件」换成「项目路径无法在当前代码页表示」。
这不需要 B,只需要 #516 已经加进去的那份记录(take_unnarrowable_paths())。

B. 给 Windows 可执行文件嵌 activeCodePage=UTF-8 清单

嵌了之后 MSVC STL 的 __std_fs_code_page() 返回 CP_UTF8,path::string() 从此返回
UTF-8 且永不抛,#516 那一整类站点一次性全对。要求 Windows 10 1903+(CI runner 满足)。

它不危险。 今天能跑通的路径全是 ASCII,而 ASCII 在 UTF-8 和 CP1252/936 下字节完全
相同 —— build.ninja、compile_commands.json、命令行一个字节不变。

真正的未知是「够不够」。 mcpp 写出 build.ninja 之后,是另一个进程
(xlings store 里的 ninja.exe,见 src/config.cppm:192)按它自己的 ACP 去读它;
编译器驱动同理。所以嵌清单只解决 mcpp 这一半,非 ASCII 路径能否端到端跑通取决于那一侧。

还需要解决的工程问题:mcpp 自建流程目前没有嵌入 Windows manifest 的能力(clang/lld 链路)。

验收标准写法(这一条比方案重要)

如果做 B,验收必须写成 「mcpp 不再抛这个异常」,不要写成 「支持 CJK 路径」。
后者要对 ninja 和编译器驱动分别测量,不能顺带宣称 —— 顺带宣称正是 #230 修完之后
#516 还能再来一次的原因。

参考

• Windows 解压包含 UTF-8 路径的归档时因多字节代码页转换失败 #516 / [bug][windows] 0.0.95 下 mcpp test --workspace 以 exit 127 中断(0.0.94 同负载全绿) #230 / fix(scanner): prune .mcpp from glob walks; never throw on unnarrowable names (#230) #231
• .agents/docs/2026-08-27-issue516-windows-acp-glob-walk-fix.md §6.2
• mcpp::modgraph::try_narrow 及 .github/tools/check_narrow_conversions.sh 的头注释