fix(tests): the Windows arm cannot compile test_backend_cross_device (#514, #540)

[localai-bot]

Closes #514. Closes #540.

Why now

windows-msvc-vulkan fails on every pull request in the repo. Both Windows jobs are gated if: github.event_name == 'pull_request' (.github/workflows/ci.yml:613, :637), so they are skipped on main pushes — main reads green while every PR opened against it reads red. That makes CI useless exactly where it matters: a real regression in someone's PR is indistinguishable from the baseline, and the failure looks like the contributor's fault.

Baseline confirmed on three unrelated PRs, all failing this same pair and nothing else:

PR	windows-msvc-cpu	windows-msvc-vulkan
#566	fail	fail
#568	fail	fail
#570	fail	fail

The Vulkan lane fails twice, not once

test_backend_cross_device.cpp is the one translation unit that job compiles beyond the shared targets, and MSVC rejects it for two independent reasons (job 94314458748):

test_backend_cross_device.cpp(513,20): error C2220: the following warning is treated as an error
test_backend_cross_device.cpp(513,20): warning C4456: declaration of 'cpu' hides previous local declaration
  ... 'cq' (514), 'cd' (515), 'ck' (516), 'cv' (516), 'cslots' (517)
test_backend_cross_device.cpp(1004,5): error C3861: 'setenv': identifier not found
test_backend_cross_device.cpp(1048,5): error C3861: 'setenv': identifier not found
test_backend_cross_device.cpp(1050,5): error C3861: 'unsetenv': identifier not found

Those are issues #514 and #540. Repairing only #514 leaves the lane red on the C2220, so both are here — same compile, same file, one fix.

#514 — the POSIX environment calls

MSVC has neither setenv nor unsetenv. The three call sites now route through file-local SetEnv/UnsetEnv, mirroring the idiom already in the tree at tests/vllm/test_gguf.cpp:83-92 (#if defined(_WIN32) / _putenv_s, POSIX otherwise).

SET and UNSET are deliberately separate entry points. test_gguf.cpp folds unset into SetEnvironment(name, ""); this file must not, because the restore arm at :1050 needs absence, and collapsing the two would silently turn "absent" into "empty".

Unset semantics — proven, not assumed

• POSIX: ::unsetenv — the byte-identical call the file already made.
• MSVC: _putenv_s(name, "") is the documented removal form. That documentation is not executable on this box, so the change does not rest on it. vt::FusedTier() (include/vt/fused_recipe.h:175-178, e != nullptr && e[0] == '1') is the only reader of VT_FUSED_TIER in the tree, and it returns 0 for absent and for empty. So even the pathological "left an empty value behind" outcome is observationally identical.

Both properties were executed:

POSIX UnsetEnv -> getenv()==nullptr: OK
FusedTier(): absent==0 and empty==0, indistinguishable: OK
SetEnv overwrite both directions: OK

The _WIN32 branch bodies were separately compiled -Wall -Wextra -Werror against the documented MSVC signature errno_t _putenv_s(const char*, const char*), which proves name, arity, argument types and order — not that MSVC's headers accept them. Only CI proves that.

#540 — the shadowed KV-cache locals

The unbind-flash-layout CPU-oracle block redeclared six names from its enclosing ReshapeAndCache test. The inner ones are renamed with an unbind_ prefix. No data, shape, stride, call or assertion moves.

Verification

Linux arm, Release, VLLM_CPP_CUDA=OFF VLLM_CPP_VULKAN=OFF, gcc 13.3.0, disk 85% used:

	test cases	assertions	status
before (base 51ec6bed5)	19 passed / 0 failed	3 passed / 0 failed	SUCCESS
after	19 passed / 0 failed	3 passed / 0 failed	SUCCESS

Assertion count is unchanged, which is the point — this is a portability change, not a coverage change.

Mutation check. Stubbing SetEnv to a no-op turns the gate RED — 18 passed | 1 failed, Status: FAILURE! — so the two REQUIRE(vt::FusedTier() == tier) assertions genuinely guard the set path. Tree restored byte-for-byte afterwards (md5 verified).

Not claimed: the Windows arm was not compiled locally. This box is Linux and has no MSVC, mingw or wine. CI is the proof and the result will be reported from the checks below, not predicted.

What this PR does not fix

windows-msvc-cpu fails for an unrelated reason — a PowerShell defect, not a compile error:

build-windows-release.ps1: Cannot bind argument to parameter 'Arguments' because it is an empty array.

That is #512, and PR #524 (row/ENG-RELEASE-WINDOWS-512) is already in flight for it. This PR is expected to leave windows-msvc-cpu red until #524 lands. See also #503, which is why this class of breakage survives on main at all.

🤖 Generated with Claude Code