The lane has moved forward
Two stacked Windows defects landed today — #664 (f8cbc2310, POSIX stat) and #720 (0011bedf0, M_PI). The honest limit recorded when they merged was that "the lane has never gotten past the LIBRARY compile, so link, the eight focused test executables, packaging and the smoke run are all still unproven."
It now gets past the library. On a branch that verifiably contains both fixes, windows-msvc-vulkan fails at a different stage — Build and execute the native Windows Vulkan focused gate, compiling a test target:
tests\vt\test_backend_cross_device.cpp(514,20): warning C4456: declaration of 'cpu' hides previous local declaration
tests\vt\test_backend_cross_device.cpp(514,20): error C2220: the following warning is treated as an error
That is progress, not a regression: a new stage is being reached for the first time.
Attribution — this one is not from the LTX-2.5 lane
tests/vt/test_backend_cross_device.cpp:514 predates that work; the line is from 822b3a2e15, 2026-08-07. It was simply unreachable until the library compiled.
The shape: an inner scope declares vt::Backend& cpu while an outer local of the same name is live. The file has six vt::Backend& cpu declarations (:230, :306, :386, :451, :514, :629), so :514 may not be the only nesting that shadows — MSVC stops at the first, exactly as it did with M_PI. Re-derive the full set at HEAD before fixing, with a positive control in the same grep, or the next 20-minute CI cycle will just reveal the next one. That has now happened twice in a row on this lane.
Why GCC and Clang never said anything
-Wshadow is not enabled for the CPU/Vulkan Linux builds, while MSVC's /W4 /WX treats C4456 as an error. So this is not a case of a warning being ignored — nothing ever emitted it. Worth deciding deliberately: either enable an equivalent locally so Linux catches the class, or accept that the Windows lane is where shadowing is found and say so.
Interaction with an open PR
#524 (row/ENG-RELEASE-WINDOWS-512) touches this same file. Whoever fixes this should check for a conflict, and #524 already carries one stale hunk — a test_backend_cross_device.cpp setenv repair that 11cc1d589 landed via tests/support/test_env.h.
Scope
Rename the shadowing locals. Do not widen /W4, disable C4456, or add a blanket #pragma warning(disable) — the warning is correct and the source is wrong, which is the same disposition #664 and #720 took.
Related: #664, #720, #584 (windows-msvc-* skipped on main, so no baseline), #680 (the portability checker's own tests run in no workflow).
The lane has moved forward
Two stacked Windows defects landed today — #664 (
f8cbc2310, POSIXstat) and #720 (0011bedf0,M_PI). The honest limit recorded when they merged was that "the lane has never gotten past the LIBRARY compile, so link, the eight focused test executables, packaging and the smoke run are all still unproven."It now gets past the library. On a branch that verifiably contains both fixes,
windows-msvc-vulkanfails at a different stage —Build and execute the native Windows Vulkan focused gate, compiling a test target:That is progress, not a regression: a new stage is being reached for the first time.
Attribution — this one is not from the LTX-2.5 lane
tests/vt/test_backend_cross_device.cpp:514predates that work; the line is from822b3a2e15, 2026-08-07. It was simply unreachable until the library compiled.The shape: an inner scope declares
vt::Backend& cpuwhile an outer local of the same name is live. The file has sixvt::Backend& cpudeclarations (:230,:306,:386,:451,:514,:629), so:514may not be the only nesting that shadows — MSVC stops at the first, exactly as it did withM_PI. Re-derive the full set at HEAD before fixing, with a positive control in the same grep, or the next 20-minute CI cycle will just reveal the next one. That has now happened twice in a row on this lane.Why GCC and Clang never said anything
-Wshadowis not enabled for the CPU/Vulkan Linux builds, while MSVC's/W4 /WXtreats C4456 as an error. So this is not a case of a warning being ignored — nothing ever emitted it. Worth deciding deliberately: either enable an equivalent locally so Linux catches the class, or accept that the Windows lane is where shadowing is found and say so.Interaction with an open PR
#524 (
row/ENG-RELEASE-WINDOWS-512) touches this same file. Whoever fixes this should check for a conflict, and #524 already carries one stale hunk — atest_backend_cross_device.cppsetenvrepair that11cc1d589landed viatests/support/test_env.h.Scope
Rename the shadowing locals. Do not widen
/W4, disable C4456, or add a blanket#pragma warning(disable)— the warning is correct and the source is wrong, which is the same disposition #664 and #720 took.Related: #664, #720, #584 (
windows-msvc-*skipped onmain, so no baseline), #680 (the portability checker's own tests run in no workflow).