main is red on two gates its own baseline lane never runs
windows-msvc-cpu and windows-msvc-vulkan are gated
if: github.event_name == 'pull_request'
(ci.yml:640), so the scheduled
and dispatched lane that scripts/main-baseline.py reads never executes
them. main-baseline.py therefore reports:
NEWEST BASELINE: GREEN at bbc482a2de73ae0c433f210c5780b52d6c886f5d
while both jobs fail on every pull request that reaches them. The baseline is
answering a question about a different set of jobs than the one a PR author is
looking at, and nothing says so.
The defect itself
tests/vt/test_cpu_isa_x86.cpp does not include <ostream>. On libstdc++ it
arrives transitively; MSVC's <string_view> does not provide it, so doctest's
stringification instantiates operator<< against an undefined
std::basic_ostream:
__msvc_string_view.hpp(550,23): error C2027: use of undefined type
'std::basic_ostream<char,std::char_traits<char>>'
[build-pr-windows-vulkan\tests\test_cpu_isa_x86.vcxproj]
__msvc_string_view.hpp(550,23): error C2065: 'iostate': undeclared identifier
...
build-windows-release.ps1:25 throw "$Program exited with status $LASTEXITCODE"
cmake exited with status 1
The file's includes are <array> <bit> <limits> <stdexcept> <string>, then
doctest/doctest.h. No <ostream>, and no <iostream>.
Reproduced on two unrelated branches, byte-for-byte
| branch |
head |
job |
first error |
row/ENG-RELEASE-WINDOWS |
673c2f3d |
windows-msvc-vulkan |
__msvc_string_view.hpp(550,23): error C2027 |
row/BENCHMARKS-CAP-RELIEF (#494) |
104d3f36 |
windows-msvc-vulkan |
__msvc_string_view.hpp(550,23): error C2027 |
Same file, same line, same failing target, same failing step ("Build and execute
the native Windows Vulkan focused gate"). #494 is a Python-only change to two
governance checkers and their mutation suites: it touches nothing under src/,
include/, tests/, cmake/, or any .ps1, so it cannot be the cause. Every
PR that reaches these two lanes gets a red X it did not earn.
Why it went unnoticed
tests/vt/test_cpu_isa_x86.cpp was last touched by #117 (49539559,
8fa2ecdb, 94f72e14), the Windows release row. The lane that would catch a
Windows-only include defect is the lane that only runs on PRs, and the row that
introduced it is itself the row whose PRs are red, so the signal reads as "the
Windows row is still in progress" rather than "main does not compile under
MSVC".
Repair
Two separable things, and the second is the one that matters:
- Add the missing
<ostream> to tests/vt/test_cpu_isa_x86.cpp. RED-before is
the MSVC build; green-after is the same lane on a PR.
- Make the main baseline honest about jobs it does not run.
scripts/main-baseline.py already prints a not run: list (pr-size,
commit-protocol-tag, documentation-checkpoint). windows-msvc-cpu and
windows-msvc-vulkan are not in it, because they are not defined for that
event at all, so they are invisible rather than listed. A GREEN verdict
that silently excludes two compiling gates is the same failure mode as a
green test run with cases skipped.
Per AGENTS.md, (2) changes a checker's semantics and needs its own spec,
red-before and green-after, with the mutation in
tests/scripts/test_main_baseline.py.
Not fixed in #494, deliberately
Found while doing #460. Not fixed there because I cannot produce green-after
evidence for it: there is no MSVC toolchain on this box, the lane is
Windows-only, and a one-line include change I cannot compile is a guess, not a
fix. tests/vt/test_cpu_isa_x86.cpp also belongs to row/ENG-RELEASE-WINDOWS,
which is in flight and red on the same job, so patching it from an unrelated row
would collide with the branch already working there.
mainis red on two gates its own baseline lane never runswindows-msvc-cpuandwindows-msvc-vulkanare gatedif: github.event_name == 'pull_request'(
ci.yml:640), so the scheduledand dispatched lane that
scripts/main-baseline.pyreads never executesthem.
main-baseline.pytherefore reports:while both jobs fail on every pull request that reaches them. The baseline is
answering a question about a different set of jobs than the one a PR author is
looking at, and nothing says so.
The defect itself
tests/vt/test_cpu_isa_x86.cppdoes not include<ostream>. On libstdc++ itarrives transitively; MSVC's
<string_view>does not provide it, so doctest'sstringification instantiates
operator<<against an undefinedstd::basic_ostream:The file's includes are
<array> <bit> <limits> <stdexcept> <string>, thendoctest/doctest.h. No<ostream>, and no<iostream>.Reproduced on two unrelated branches, byte-for-byte
row/ENG-RELEASE-WINDOWS673c2f3dwindows-msvc-vulkan__msvc_string_view.hpp(550,23): error C2027row/BENCHMARKS-CAP-RELIEF(#494)104d3f36windows-msvc-vulkan__msvc_string_view.hpp(550,23): error C2027Same file, same line, same failing target, same failing step ("Build and execute
the native Windows Vulkan focused gate"). #494 is a Python-only change to two
governance checkers and their mutation suites: it touches nothing under
src/,include/,tests/,cmake/, or any.ps1, so it cannot be the cause. EveryPR that reaches these two lanes gets a red X it did not earn.
Why it went unnoticed
tests/vt/test_cpu_isa_x86.cppwas last touched by #117 (49539559,8fa2ecdb,94f72e14), the Windows release row. The lane that would catch aWindows-only include defect is the lane that only runs on PRs, and the row that
introduced it is itself the row whose PRs are red, so the signal reads as "the
Windows row is still in progress" rather than "main does not compile under
MSVC".
Repair
Two separable things, and the second is the one that matters:
<ostream>totests/vt/test_cpu_isa_x86.cpp. RED-before isthe MSVC build; green-after is the same lane on a PR.
scripts/main-baseline.pyalready prints anot run:list (pr-size,commit-protocol-tag,documentation-checkpoint).windows-msvc-cpuandwindows-msvc-vulkanare not in it, because they are not defined for thatevent at all, so they are invisible rather than listed. A
GREENverdictthat silently excludes two compiling gates is the same failure mode as a
green test run with cases skipped.
Per AGENTS.md, (2) changes a checker's semantics and needs its own spec,
red-before and green-after, with the mutation in
tests/scripts/test_main_baseline.py.Not fixed in #494, deliberately
Found while doing #460. Not fixed there because I cannot produce green-after
evidence for it: there is no MSVC toolchain on this box, the lane is
Windows-only, and a one-line include change I cannot compile is a guess, not a
fix.
tests/vt/test_cpu_isa_x86.cppalso belongs torow/ENG-RELEASE-WINDOWS,which is in flight and red on the same job, so patching it from an unrelated row
would collide with the branch already working there.