ci: 新增 Windows 10 / 11 双 job(含完整测试段),并修复 mcpp 索引下限导致的全平台 CI 红

[Sunrisepeak]

做了什么

1. Windows 10 / 11 两条产品线的 CI

build-windows 从单个 windows-latest 改成矩阵。GitHub 托管 runner 没有
Windows 客户端版的 x64 镜像,只有 Server 镜像;这里用与各自客户端版共享内核基线的
Server 镜像代表两条线。job 里会打印实际 caption / build 号存证 —— 本次 CI 实测:

job	runner	实测 caption	build
windows-10 baseline	windows-2022	Windows Server 2022 Datacenter	10.0.20348(= Win10 22H2)
windows-11 baseline	windows-2025	Windows Server 2025 Datacenter	10.0.26100(= Win11 24H2)

2. 两个 Windows job 都跑完整测试段

不再只是「能编过」:

构建 → 版本自检 → 协议一致性 e2e(tests/e2e.sh) → d2mcpp 真课程 checker 冒烟

为此把测试脚本改成可移植形式:

• 练习目录改经位置参数传入,不再用 FAKE_DIR=... bash ... 环境变量前缀 ——
  Windows 上 d2x 经 _popen 走 cmd.exe 启动 Provider,cmd 没有这种语法。
• 交给 d2x 的路径先经 cygpath -m 转成 C:/...:d2x 是原生 exe,认不得 /tmp/...
  这类 MSYS 路径;bash 同样接受该写法,两边通用。
• 活性超时一组也在 Windows 跑起来了 —— 见下面「一并修掉的 bug」第 2 条。

3. 顺带修复一处既有的全平台 CI 故障

与本次改动无关,但不修则 CI 不可能全绿:

error: index requires mcpp >= 0.0.109 but this is mcpp 0.0.104 [E0006]

mcpplibs 依赖索引已把 index floor 抬到 0.0.109,原先钉的 mcpp 0.0.104 一律拒绝
解析 compat.ftxui 等依赖。在 main 上重跑 2026-07-23 那次全绿的 CI(run 30053559836),
如今五个 job 全红 —— 属上游索引变动导致的既有故障。

升到索引 latest ref 2026.8.1.1(.xlings.json + MCPP_VERSION 同步)。
d2mcpp 上游同样仍钉 0.0.104,故冒烟前先把课程侧的 pin 对齐;上游跟进后可移除该步骤。

冒烟判据分两档(刻意的,不是笼统放宽)

首轮 CI 两个 Windows job 红。查下来不是 d2x 的问题:checker 确实走完了
「读配置 → 拉起 Provider → 枚举 52 道练习 → 选中第一题 → 渲染练习页」,
Exercise: hello-mcpp / Status: ❌ failed 都在。断的是课程 Provider ——
它在 Windows 上拿不到 mcpp test --message-format json 的记录。

原判据 grep -qiE "error" 是照 linux 写的:那个 error 串来自课程的真实编译错误,
依赖上面那条断掉的上游链路,在 Windows 上不可能出现。所以:

• 共通(d2x 自己的职责):hello-mcpp + Exercise: + Status: 三串同时出现,
  即「渲染出了第一题」,而不是卡在加载日志上。
• linux 仍是最严的一档:在上面基础上额外要求透出课程编译错误 —— 整条链路在
  linux 上是通的,这条不能松。
• Windows 暂不要求后者,注释里写明这是上游缺口、补齐后应收紧到与 linux 一致。

新增的 Provider 原始 NDJSON 诊断步骤把根因摆进了日志:

{"event":"stage","name":"compile"}
The system cannot find the path specified.
{"event":"error","message":"mcpp test 没有返回 'hello-mcpp' 的记录..."}

mcpp test 在 Windows 上先以「找不到路径」失败,压根没输出 JSON —— 待报 mcpp / d2mcpp
上游。d2x 侧行为是正确的:协议规定「Provider 没给 verdict 即 fail」
(tests/e2e.sh 场景 1b 钉的就是这条),页面也如实显示 failed。

验证

CI run 30702841729,六个 job 全绿;两个 Windows job 的 checker 步骤实测:

checker exit=124 (124 = killed by timeout while waiting for edits = expected)
Exercise: hello-mcpp (intro)
Status:   ❌ failed
OK: checker reached and rendered the first exercise (not stuck on the loading log)

一并修掉的 bug(都是新 CI 暴露出来的)

1. normalize_path 在 Windows 上留下前导分隔符

练习页显示成 \src\intro\tests\hello-mcpp.cpp,linux 上是正确的
src/intro/tests/hello-mcpp.cpp。根因是手写的「前缀匹配 + 掐掉一个 '/'」只认
'/',Windows 分隔符是 '\' 掐不掉。(相对化本身是有意行为,坏的只是这个分隔符。)

改用 std::filesystem::path::lexically_relative,分隔符与 .. 情形交给标准库;
输出统一 generic_string()。Win10 / Win11 CI 实测已修复,两平台都输出
src/intro/tests/hello-mcpp.cpp。

回归测试落在 tests/e2e.sh 场景 5(展示路径不得以分隔符打头)。这条断言起初写成
单条正则 ^File: +[^\\/].*ex1\.txt,但 + 会回溯让字符组吃掉一个空格,四种
输入全部放行 —— 实测发现后拆成两条判断。

2. Windows 没有活性超时(挂死的 Provider 不会被终止)

run_lines_idle 此前在 _WIN32 下显式回退为「无超时运行」,Windows 上挂死的
Provider 会把 checker 一起拖住;e2e 的活性超时一组也因此在该平台跳过。

现用 Job Object 补齐(protocol/src/process.cppm),语义对齐 POSIX 分支的
kill(-pid) —— 终止的是整棵进程树,而不只是直接子进程(Provider 常有孙进程
mcpp → 编译器)。要点:CREATE_SUSPENDED 先挂起、纳入 Job 再 ResumeThread,
避免孙进程逃逸出 Job;读端去继承 + 父进程立刻关写端,否则读不到 EOF;全程
PeekNamedPipe 探量再读,绝不裸调 ReadFile(管道读阻塞会把活性判定一起拖死)。

tests/e2e.sh 已去掉 Windows 跳过分支,五组协议测试三平台同跑。这条在 CI 里
是有效判据:hang 模式下 Provider 是 cmd.exe → bash → sleep 300 的一棵树,
只杀直接子进程的话 sleep 会活下来,20s 窗口内同样出不了 verdict。

未覆盖 / 待办

• macOS job 仍只做构建 + 版本自检:macOS 不自带 GNU timeout,tests/e2e.sh
  需要额外的可移植性改造。可另开 PR。
• 上游 mcpp / d2mcpp:mcpp test 在 Windows 上以「找不到路径」失败,导致课程
  Provider 发不出 verdict(诊断步骤的原始输出见上)。不在本仓库,待另行上报。