fix(link): 命令长度上限从架构上消掉,不再补第八个洞 (2026.8.5.4)

[speak-agent]

mcpp-index 的 opencv-module 在 windows 上 LNK1170 —— 同一族缺陷的第七次。

设计文档:.agents/docs/2026-08-06-command-length-architecture.md

七次

#	谁超了	上限	失败长什么样
#247	链接内联 $in,数千对象	CreateProcess 32 KiB	—
#261	shell 重定向 → 被 cmd /c 包裹	cmd.exe 8191	—
#261	无界 -I 列表	cmd.exe 8191	—
#274	显式目标集(FFmpeg 2281 单元 → 50 781 字符)	cmd.exe 8191	裸 127,谁都没机会打印
#344	对象路径变长 → 161 687 字节	POSIX MAX_ARG_STRLEN 128 KiB	Argument list too long,不说哪条边
2026.8.5.3	rspfile 全写一行	link.exe 单行 128 KiB	LNK1170,不说哪个 target
本次	clang driver 又生成一个单行 rspfile	同上	编译 356 秒后才炸

共同形状:发现方式永远是崩溃,且崩在最后一步;失败不可归因;触发者从来不是「写了很长的命令」 —— #344 是修缓存正确性,#274 是改错误粒度,本次是把 CI 的 pin 抬过 2026.8.3.4。

每次修完都在注释里写「构建系统不该有靠崩溃才发现的规模上限」,然后换个地方再犯。

为什么现在才出现

#344 给每个依赖的对象加了一层包目录(缓存正确性要求),路径因此变长 —— 同一条边在 linux 上从 56 840 涨到 161 687 字节。而 mcpp-index 的 CI 一直 pin 在 2026.8.3.3,正好是那之前一版,它的 windows 腿从没用长路径链接过。抬 pin 才第一次撞到。

根因:一个关键约束在零处被表达

命令实际穿过的是一条链:

mcpp 拼出的规则文本
  → ninja 展开(内联 or rspfile)
    → 进程创建(CreateProcess / posix_spawn / sh -c)
      → 工具自身(driver 可能再写一个 rspfile 转发)
        → 最终工具(link.exe / lld / ar)

每层上限互不相同,而构造层不知道自己会穿过哪几层。这是本仓库反复付学费的「同一决策在 N 处推导」的镜像。

P1 — 让长度不再是变量

2026.8.5.3 把 mcpp 自己写的响应文件改成按行分隔。但 clang 作为 driver 会再生成一个转发给链接器,那个是单行的 —— 我们改不到它。所以 windows 上的 clang 链接改用 -fuse-ld=lld。

为什么这不是 workaround(这一条是本 PR 的关键判断):

• lld 用 LLVM 的 tokenizer 解析响应文件,没有单行上限 —— 消掉的是一整类,不是把某个数字调大;
• 路径缩不短:那层包目录正是 [bug] 全局 build cache:obj 布局随消费方包组合变化(#233 消歧),而 cache key 不含消费方 → 同一 key 下第二个消费者必挂 'missing and no known rule' #344 需要的,其余是源码树自身结构 —— 缩回去是拿正确性换长度;
• linux 与 macOS 早就在用 lld(kLinkDriverFlags)。windows 是唯一还在用系统链接器、也是唯一有单行上限的平台。这是消除平台不一致,不是新增特例。

原生 cl.exe 保持 link.exe:那条路径上响应文件是我们自己写的,2026.8.5.3 已覆盖。

P2 — 上限进表(新模块 cmdlimits.cppm)

把「执行通道 → 上限」变成数据。表里除字节数还记症状,因为这一族最贵的从来不是修,是认出:Argument list too long、LNK1170、裸 127 三种表现毫无共同点,下次第四种时表能直接把人指过来。

新增执行通道必须回答「你的上限是多少」 —— 与 directives::kTable 里「Scope 是必填字段」同一手法:把容易忘的问题变成结构上绕不过去的字段。

P3 — 计划期拦截并指名道姓

生成完 build.ninja 统一扫描,超限时报出边名 / 通道 / 实测字节 / 上限 / 解法 / 文档路径,且发生在还没编译任何东西的时候 —— 而不是 356 秒之后由别人的程序报一个没有上下文的错。

实施中纠正了两处判断:

1. 校验点选「manifest 生成后统一扫描」而非「逐 emit site 插桩」—— 后者在新增一种边时没人会想起来加,而那正是前七次的漏法。
2. phony 必须排除,否则会误报到 feat: mcpp test capability batch — isolation, parallel, filter, list, timeout, JSON (0.0.104) #274 的修复本身:它为解决 argv 超限,正是把几千个目标收进一条 phony 聚合边 —— 而 phony 根本没有 command。不排除的话,新校验会把解法报成问题。走 rspfile 的规则同样豁免。判据是「rule 有 command 且不走 rspfile」。

测试

• 单测 test_cmdlimits 8 条:每个通道都在表里、数字是实测的那些(MAX_ARG_STRLEN 是 32 页,不是谁都会先想到的 2 MiB ARG_MAX —— [bug] 全局 build cache:obj 布局随消费方包组合变化(#233 消歧),而 cache key 不含消费方 → 同一 key 下第二个消费者必挂 'missing and no known rule' #344 为此花了一个版本)、每条都记了症状与解法、诊断含边名/字节/上限/解法/文档路径。
• 全量单测 58/58;mcpp 自身 351 条边零误报;链接相关 e2e(28/47/86/07/148/190)绿。
• 没做超限 e2e,说明原因:P1 之后本地造不出自然超限的边,要造只能人为破坏 rspfile 规则 —— 那测的是被破坏的代码而不是真实路径。windows 的真实验证由 mcpp-index CI 承担。

其他

内带 xlings 升到 2026.8.5.2,.github/ 下 16 处 pin 由 check_version_pins.sh 校验同步。

那个脚本当场抓到 7 处不同步(含 5 处带 v 前缀的),并且拦下了我一次误改:全局替换差点把它自己注释里的历史记录(available: 2026.8.5.1,那是当时的事实)一并改掉。