The MSVC toolchain and Clang driver combination currently uses a fairly complex
sequence of steps to determine the MS compatibility version to pass to cc1.
There is some oddness in this sequence currently, with some code which inspects
flags in the toolchain, and some code which inspects the triple and local
environment in the driver code.
This change is an attempt to consolidate most of this logic so that
Win32-specific code lives in MSVCToolChain.cpp. I'm not 100% happy with the
split, so any suggestions are welcome.
There are a few things you might want to watch for for specifically:
- On all platforms, if MSVC compatibility flags are provided (and valid), use those.
- The fallback sequence should be the same as before, but is now consolidated into MSVCToolChain::getMSVCVersion:
- Otherwise, try to use the Triple.
- Otherwise, on Windows, check the executable.
- Otherwise, on Windows or with --fms-extensions, default to 18.
- Otherwise, we can't determine the version.
- MSVCToolChain::ComputeEffectiveTriple no longer calls the base ToolChain::ComputeEffectiveClangTriple. The only thing it would change for Windows the architecture, which we don't care about for the compatibility version.
- I'm not sure whether this is philosophically correct (but it should be easy to add back to MSVCToolChain::getMSVCVersionFromTriple if not).
- Previously, Tools.cpp just called getTriple() anyhow, so it doesn't look like the effective triple was always being used previously anyhow.
This isn't a cheap operation, and we don't cache it. Let's call it something like computeMSVCVersion. I don't want us to read the version out of cl.exe more than once. Besides, it mirrors ComputeLLVMTriple etc.