degski wrote:
This *surely* needs the clang-win toolset since one is (wants to be) using the Dinkumware (VC++'s) STL.
LLVM Clang finds and uses the 14.1 headers for me when using the clang-linux toolset. I could tell because it gave me errors in these headers when I wasn't supplying -fms-version=1910. clang-win is outdated. It's predicated on the assumption that the Windows Clang would be a separate animal, a drop-in replacement for Microsoft's cl.exe. This was the original plan, but it has been abandoned for at least a year now, if not more. Clang under Windows is more or less the same as Clang under Linux now, except that it targets the Microsoft ABI (and fails to link). Visual Studio 2017 doesn't use clang-cl.exe, it understands Clang's options natively and uses clang.exe. A proper clang-win toolset today would treat Clang as Clang, not as cl.exe, only it would replace the link phase with a working one. And a proper clang-c2 toolset would do the same except it would use 14.0/14.1 as the version and look for clang.exe at the appropriate locations.