Windows: no way to work around MSVC 14.51 STL ↔ Clang 19 mismatch (windows-2025 + Swift 6.1/6.2)

[leogdion]

Problem

On the windows-2025 runner, building with Swift 6.1 or 6.2 fails inside swift-crypto's CCryptoBoringSSL:

yvals_core.h:917:1: error: static assertion failed:
error STL1000: Unexpected compiler version, expected Clang 20 or newer.

Root cause is environmental, not a consumer-package bug:

• The windows-2025 image now exposes a newer MSVC 14.51 toolset (VS18). The Swift/clang driver resolves the newest installed Visual Studio via vswhere, so it picks 14.51, whose STL (yvals_core.h) hard-asserts Clang 20 or newer.
• Swift 6.1 and 6.2 bundle Clang 19 → assertion fires. Swift 6.3 bundles Clang 20 and is fine.
• windows-2022 still defaults to an older 14.4x toolset compatible with Clang 19, so it builds all three.

Because the Windows build is delegated entirely to this action (gha-setup-swift + swift build), a consumer has no lever to work around it — the action exposes only windows-swift-version / windows-swift-build. There's no windows-swift-flags (unlike wasm-swift-flags / android-swift-build-flags) and no toolset selection, so neither of the two known mitigations can be applied through the action.

Impact

Every package using brightdigit/swift-build@v1 with a [windows-2022, windows-2025] × [6.1, 6.2, 6.3] matrix hits this identically. Today the only fix a consumer can apply is at the matrix level — dropping windows-2025 × {6.1, 6.2} (e.g. brightdigit/MistKit#418) — which loses windows-2025 coverage for those toolchains.

Requested: give consumers a workaround knob

Any one of these would unblock callers who want to keep windows-2025 coverage:

1. windows-swift-flags input (mirrors wasm-swift-flags / android-swift-build-flags) appended to the Windows swift build/swift test. Callers could then pass:

   windows-swift-flags: -Xcc -D_ALLOW_COMPILER_AND_STL_VERSION_MISMATCH
   

   This silences the STL static_assert. Caveat: it pairs Clang 19 codegen with a 14.51 STL, so it's a bypass, not a true fix — see [Windows] Consider passing -D_ALLOW_COMPILER_AND_STL_VERSION_MISMATCH to Clang by default swiftlang/swift#79709.

2. MSVC toolset pin input (e.g. windows-vc-toolset: "14.44"): before the build, activate VS2022's older 14.44 toolset (set INCLUDE/LIB/PATH/VCToolsInstallDir, or write Microsoft.VCToolsVersion.default.txt) so the Swift driver uses a Clang-19-compatible STL. 14.44 ships on the windows-2025 image (VS2022 17.14) alongside 14.51.

3. Auto-mitigation + docs: detect the Swift toolchain's bundled Clang major vs. the default MSVC STL's required Clang, and either auto-select a compatible installed toolset or emit a clear, documented error pointing at options 1/2. At minimum, document the matrix-exclude workaround.

Option 1 is the smallest change and matches the existing per-platform *-swift-flags pattern; option 2 keeps codegen/STL aligned but is more involved.

References

• Consumer-side workaround (matrix exclude): Skip windows-2025 Swift 6.1/6.2 in CI matrix (MSVC 14.51 STL needs Clang 20) MistKit#418
• Upstream discussion of the default bypass flag: [Windows] Consider passing -D_ALLOW_COMPILER_AND_STL_VERSION_MISMATCH to Clang by default swiftlang/swift#79709
• Runner-image tracking: Building on windows-latest sporadically has random LLVM version for bindgen actions/runner-images#12435

🤖 Generated with Claude Code

[leogdion]

Mechanism already exists upstream — compnerd/gha-setup-vsdevenv's toolset_version

Checked the action we actually call. compnerd/gha-setup-swift (the one swift-build uses) has no toolset/vcvars/flags knob — inputs are just source, swift-version, swift-build, build_arch, branch, tag, github-repo, release-tag-name, release-asset-name, github-token, installer-args, update-sdk-modules, cache. And it only runs a VS dev-env setup (VS2022 Compatibility Setup) when Swift ≤ 5.9 (is_newer_than_5_9 == 'false'); for Swift 6.x it skips that, so the Swift driver auto-detects the newest VS (14.51) at build time → the failure.

However, its sibling compnerd/gha-setup-vsdevenv already exposes the right inputs:

• toolset_version — "Overrides the default toolset version"
• winsdk — override WinSDK version
• components — required VS components
• arch / host_arch / vswhere / verbose

So the toolset pin doesn't need anything new from compnerd — it's a matter of wiring gha-setup-vsdevenv (with toolset_version) into the Windows build path.

Option A — windows-vc-toolset input in this action (preferred)

Add a windows-vc-toolset input and, when set on Windows, run gha-setup-vsdevenv before swift build/swift test so the older toolset's INCLUDE/LIB/PATH win:

- name: Pin MSVC toolset (Windows)
  if: steps.detect-os.outputs.os == 'windows' && inputs.windows-vc-toolset
  uses: compnerd/gha-setup-vsdevenv@v6
  with:
    arch: ${{ inputs.build_arch == 'arm64' && 'arm64' || 'amd64' }}
    toolset_version: ${{ inputs.windows-vc-toolset }}

Consumer usage to keep windows-2025 coverage for Swift 6.1/6.2:

- uses: brightdigit/swift-build@v1
  with:
    windows-swift-version: ${{ matrix.swift.version }}
    windows-swift-build: ${{ matrix.swift.build }}
    windows-vc-toolset: '14.44'   # only when runs-on == windows-2025 && swift < 6.3

14.44 ships on the windows-2025 image (VS2022 17.14) alongside 14.51, so nothing extra to install.

Option B — windows-swift-flags input (smallest change, but a bypass)

Mirror wasm-swift-flags / android-swift-build-flags; append to the Windows build/test:

windows-swift-flags: -Xcc -D_ALLOW_COMPILER_AND_STL_VERSION_MISMATCH

Silences the STL1000 static_assert but pairs Clang 19 codegen with a 14.51 STL — works, not "correct" (see swiftlang/swift#79709). Useful as a generic escape hatch beyond this specific case.

Option C — consumer-side today, no release needed

Callers can already drop the same gha-setup-vsdevenv step before brightdigit/swift-build@v1 in their own workflow. Worth verifying on CI that the Swift driver honors the injected INCLUDE/LIB over vswhere's newest — if it does, Option A is just promoting this into the action.

Recommendation

Option A as the real fix (keeps codegen/STL aligned, reuses compnerd's toolset_version); Option B alongside it as a low-cost general escape hatch. A CI check on Option C first would de-risk both, since all three depend on the Swift/clang driver respecting the dev-env INCLUDE/LIB.