test(e2e): 覆盖链接命令的「规模」轴 —— 此前没有任何 CI job 到得了 (#346) - #362
Merged
Conversation
…#346) Every mcpp CI job builds either mcpp itself (tens of TUs) or a synthetic e2e project (single digits). Link-line length, the response-file path and ninja graph size over a large object set therefore had no coverage at all, and the whole command-length defect family surfaced in the ecosystem instead: #274 ninja goals argv 50781 chars vs cmd.exe 8191 #247 Windows CreateProcess 32 KiB #345 POSIX MAX_ARG_STRLEN 128 KiB #360 link.exe LNK1170, response-file line capped at 128 KiB 190 asserts the shape of the generated rule at 25 objects. 191 asserts the scale: 1400 C TUs whose object list is 140 KiB, past the largest command-line ceiling in cmdlimits.cppm, required to link and to run. The regime is asserted rather than assumed. Object naming, the disambiguation prefix and the file count all influence how large the list actually is, so the response file's size is checked against the ceiling directly: if it ever falls back under, the test reports that it has stopped covering the axis instead of passing quietly. Verified to fail without the fix — reverting the generated cxx_link rule to its pre-#345 inline form on this project reproduces the original symptom verbatim: `ninja: fatal: posix_spawn: Argument list too long`. Cost: 1.3s wall on a developer machine. Padded file names carry the object paths to ~100 bytes so the ceiling is reached at a file count this small, bounded on the other side by Windows MAX_PATH.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
缺口
mcpp 的每个 CI job 构建的要么是 mcpp 自身(几十个 TU),要么是 e2e 里的合成小工程(个位数)。链接行长度、响应文件路径、大对象集下的 ninja 图规模,覆盖率为零。 于是这一族缺陷全部由生态侧崩出来,而不是 CI:
MAX_ARG_STRLEN128 KiB修复前
opencv-module的内联链接行已经是 56 840 字节,占上限 43% —— 这条线一直悬着,只是没有任何测量在看它。这个测试补的是哪一半
190_link_rspfile_newlines.sh断言生成规则的形状(rspfile_content = $in_newline,25 个对象)。191_link_scale.sh断言规模:1400 个 C TU,对象清单 140 KiB,超过cmdlimits.cppm中最大的那条命令行上限,要求它能链接、能运行。区间被断言,而不是被假定
对象命名、消歧前缀、文件数都会影响清单的实际大小。任何一个把它缩回上限以下,测试都会继续通过而不再覆盖任何东西。所以响应文件的字节数被直接与上限比较 —— 一旦落回,测试报告「它已不再覆盖它存在的理由」,而不是安静地绿。
已验证会红
把生成的
cxx_link规则退回 #345 之前的内联形态,在这个工程上逐字复现原始症状:代价
本机 1.3 秒(1400 个 TU,并行)。文件名做了填充,使每个对象路径约 100 字节 —— 用编译时间(昂贵)换路径长度(免费),这才是文件数这么小就能到 128 KiB 的原因。另一侧的边界是 Windows MAX_PATH:相对 100 字节,加临时目录与构建目录后接近 260 中的 200。
仅测试改动,不改引擎,因此不带版本号。