windows-msvc-cpu is red on main and every PR: check-windows-portability reads the vendored BoringSSL /w as a project-wide negation of /W4 /WX

[localai-bot]

windows-msvc-cpu is RED on main and on every pull request, and the cause is one /w token the vendored BoringSSL targets legitimately want.

The verdict, and it is not a compile failure. scripts/build-windows-release.ps1:31 runs scripts/check-windows-portability.py before anything is compiled, and that checker exits 1 with:

ERROR: CMakeLists.txt: MSVC /W4 /WX policy is negated on the C/C++ compile by /w

Measured on 9f13751c3 (PR #1633's head) in job 96949585684: the failure lands at 00:39:38, seventeen seconds after Build files have been written to, so no translation unit is ever read. The job's own log carries no error C#### and no error LNK####.

It is not that pull request's doing, and it is not #503, #603 or #965. #603 is test_backend_cross_device.cpp using POSIX setenv; #965 is a C4456 shadow in server_main.cpp; #503 is the baseline-reporting hole. None of them is a checker refusal, and none names this string. PR #1633 does not touch CMakeLists.txt at all.

Isolated to one token. CMakeLists.txt:2441 reads

      # Vendored code is not on this project's -Werror path.
      foreach(_boringssl_target ssl crypto)
        if(TARGET ${_boringssl_target})
          target_compile_options(${_boringssl_target} PRIVATE
            $<IF:$<CXX_COMPILER_ID:MSVC>,/w,-w>)
        endif()
      endforeach()

Replacing that generator expression with a bare -w -- dropping only the MSVC arm -- makes the same checker print Windows portability contract OK. The tree was restored byte-for-byte and re-hashed after the probe.

Which side is wrong is a real decision and is why this is filed rather than fixed in flow. The /w is deliberate and correct: it is PRIVATE on two FETCHED third-party targets, and the comment above it says so. What the checker cannot currently see is scope -- it reads /w anywhere in CMakeLists.txt as a project-wide negation of /W4 /WX, which is true of a global add_compile_options(/w) and false of a target_compile_options(<vendored> PRIVATE /w). Teaching it that distinction is a semantic checker change, so AGENTS.md ## Changing the rules or a checker requires a spec, a red-before test and green-after evidence rather than an in-flow edit. The alternative -- keeping BoringSSL's warnings on this project's -Werror path on MSVC -- would put a vendored dependency's diagnostics into this repository's gate, which is what the comment exists to prevent.

Introduced by a50c57d69 (#1505, row ENG-HF-MODEL-DOWNLOAD, issue #1280), which added the static-BoringSSL transport. git log -S'$<IF:$<CXX_COMPILER_ID:MSVC>,/w,-w>' -- CMakeLists.txt returns that commit alone.

Found while repairing the fresh-review findings on #1633. That branch reads the red, is not its cause, and does not repair it: the fix needs its own row, spec and fresh review.

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: AGENT:claude-opus-5 [Claude Code]