See internal thread "Is it time to drop the MSVC bots?". We want to turn down the MSVC bots once we can. What exactly "once we can" means isn't quite pinned down.
We do want to keep msvc support in the gn build files, so that subprojects that want to keep supporting msvc can do so. ANGLE does want to do that, and for that we need to fix issue 786460 and issue 820421 .
V8 probably wants to stay buildable with MSVC too (yangguo, do you know who has an opinion on this), but that shouldn't require any work except keeping the msvc support in the gn files around. (We might want to do something like issue 776284 for msvc to check the gn files eventually.)
Other things to discuss is warning parity. The only two things I know about that msvc warns on that we currently don't tell clang to warn on is unreachable code (issue 346399) and some conversion warnings (a subset of issue 588506). If that's a hard blocker is up for discussion; I'll start a thread on cxx@ in a second.
Another thing up for discussion (but again in that thread) is the libc++ story. We're actively looking at using libc++ on Windows ( issue 813553 ). This works well with clang, but we haven't tested it with cl.exe, and there's some evidence that cl.exe + libc++ might not yet work. Do we make libc++ work with cl.exe and span the full (clang-cl, cl.exe) x (ms stl, libc++) space, or do we say we only do libc++ with clang, and people who want to use cl.exe need to make sure that the codebase stays buildable with cl.exe but also with ms stl once we move to libc++?
Comment 1 by thakis@chromium.org
, Mar 9 2018