Edward Diener wrote:
Try running all the Boost PP tests <g>. I would be very surprised if they worked in -fno-ms-compatibility mode. I will try it myself with clang targeting VC++ using clang-win.
I tried and failed. Clang/C2 in VS 2017 is in C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\ClangC2\14.10.25903\bin\HostX86\clang.exe so I put using clang : 14.1 : "C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/ClangC2/14.10.25903/bin/HostX86/clang.exe" : <cxxflags>-fno-ms-compatibility <linkflags>-v ; in user-config.jam. This failed with "can't find c2". I then tried a VS2017 developer command prompt. Clang then compiles, but linking fails with: clang-linux.link ..\..\bin.v2\libs\mp11\test\mp_remove_if.test\clang-linux-14.1\ debug\mp_remove_if.exe clang with Microsoft CodeGen version 3.8.0 Provided as - is without support C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\ClangC2\14.10.25903\bin\HostX86\x86\c2.dll version 19.10.25903.0 Target: i686-pc-windows-msvc Thread model: posix InstalledDir: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/ClangC2/14.10.25903/bin/HostX86 "link.exe" "-out:..\\..\\bin.v2\\libs\\mp11\\test\\mp_remove_if.test\\clang-linux-14.1\\debug\\mp_remove_if.exe" -defaultlib:libcmt -nologo -debug --start-group "..\\..\\bin.v2\\libs\\mp11\\test\\mp_remove_if.test\\clang-linux-14.1\\debug\\mp_remove_if.obj" -Bstatic -Bdynamic --end-group clang.exe: error: unable to execute command: program not executable clang.exe: error: linker command failed with exit code 1 (use -v to see invocation) So, Clang/C2 can't link for some reason. The link rule probably needs to be changed to use link.exe, but that's beyond my capabilities right now.
Ideally if clang targeting VC++ actually emulated the VC++ non-standard preprocessor perfectly BOOST_PP_VARIADICS_MSVC=1 would absolutely have to be defined in order for clang targeting VC++ to work properly with Boost PP.
Bug compatibility with cl.exe has never been a Clang goal. The point of -fms-compatibility was to compile MS's headers. Those however have improved to a point where they work in -fno-ms-compatibility mode, and this is default in 2017 now. So I think that we can ignore -fms-compatibility from now on as there's no need to use it.