RFC: Drop MSVC as a supported compiler on Windows (keep clang-cl) #36153

Continues the 2026-08-13 IRC meeting discussion.

Proposal

Stop supporting MSVC (cl.exe). Native Windows builds use clang-cl.exe (#31507). Release binaries are unaffected (mingw-w64 cross-compile in Guix).

Motivation

• MSVC is the only compiler we use that we cannot fix: no upstream patches, ineffective bug reporting. Also see historical ICE workarounds.
• As far as we know, every MSVC-specific issue found so far has been a compiler bug, not a codebase bug. More of them are expected as we adopt C++23/26.
• Windows keeps two toolchains (mingw-w64 cross, clang-cl native); CI job count unchanged.
• clang-cl still uses the MS STL, so standard-library diversity is retained.

The only drawback is reduced compiler diversity in what the codebase is built and tested against.

What changes (commit 96d2380dc40e703e342dc0fad5d294cc49b25ff9 in #31507)

Removed: MSVC CI jobs; MSVC docs; MSVC-specific CMake flags and diagnostics.

Kept: CMake does not reject MSVC; source-level _MSC_VER guards (shared with clang-cl).

Policy: MSVC is unsupported, no CI, MSVC-only workarounds not accepted.

#24773 will be closed, as no longer needed to fix performance issues.

Users' perspective

From the users' perspective, the binaries produced by MSVC are strictly inferior.

Concept ACK, just restating some of the things said on IRC: losing compiler diversity is unfortunate but given that MSVC is closed-source, gleaning information from any problems it surfaces is difficult, and their process for dealing with internal bugs is opaque.

see e.g. #31303 and #32499 (comment) where e.g. it was not even clear what version fixed an internal issue.

Concept ACK

It seems like MSVC is causing us a lot of overhead, and very limited actual benefits. Unless there are strong indications that MSVC is going to take a different course (e.g. becoming fully open-source, better support, ... ) in the near term (I can't find them), it seems best to drop MSVC.

For reference, here is the relevant IRC conversation (would be useful to link in OP).

I think it would also be useful to be explicit about what dropping support means. In my book, that means when evaluating a change, MSVC support must be discounted completely. That would also mean that PRs that remove MSVC-specific code would be equivalent to cleaning up dead code, and thus generally welcomed if people want to work on it.