On 3/27/2016 6:15 PM, Niall Douglas wrote:
On 26 Mar 2016 at 6:52, Edward Diener wrote:
The clang build which targets VC++ on Windows, as opposed to the clang build which targets mingw(-64)/gcc on Windows, 'emulates' the non-standard VC++ preprocessor so it can compile Windows API headers and VC++ header files. Exactly what VC++ preprocessor 'bugs' it emulates and how successful this emulation is I do not know, but I know it is done because I was told of it in the clang developer forum and I encountered a clang targeting VC++ preprocessor 'bug' which was explained to me as an emulation of VC++.
As of VS2015 Update 2 RC, the MSVCRT, STL and Windows SDK headers supplied no longer require clang to act in MSVC compatibility mode to compile. I am compiling AFIO v2 for windows using LLVM clang with these options:
clang.exe -fpic "stdafx.h" -fmsc-version="1900" -std=c++1y "x64\Debug clang\" -Wall -fstrict-aliasing -I "../include" -g2 -gdwarf-2 -O0 -x c++-header -U "__STDC__" -D "WIN32" -D "_DEBUG" -D "_WINDOWS" -D "_USRDLL" -D "BOOST_AFIO_EXPORTS" -D "_UNICODE" -D "UNICODE" -D "UNICODE=1" -D "_UNICODE=1" -D "AFIO_STANDALONE=1" -frtti -fno-omit-frame-pointer -fno-ms-compatibility -fexceptions -o "x64\Debug clang\%(filename).obj" -fms-extensions -fno-short-enums
The key improvement with VS2015 Update 2 is the -fno-ms-compatibility is now possible even when using the Dinkumware STL, the Parallel Patterns Library or the Windows SDK. This means that clang treats your code as strictly as normal, and it is *very* useful for linting your code (the complete C++ 14 language support is also very handy).
Note that I cannot get MSVCRT-as-a-dll working with this configuration, for that you still need -fms-compatibility. MSVCRT-as-a-static-library is working. I assuming this is a RC related problem which will be fixed soon, the cause is the char16_t and char32_t support misdetection.
I am not using any preprocessor tricks which are incompatible with MSVC, so I cannot say if the broken preprocessor emulation is still present with -fno-ms-compatibility. I would suspect not. -fms-extensions are things like declspec markup support, I am not aware of it changing any parsing behaviour.
I do not have any idea any longer which versions/implementations of clang 'emulate' the VC++ preprocessor currently. There now appear to be standalone versions of llvm/clang as always and versions of clang which are part of a VC++ release, whic allow clang to be used as the backend compiler. I haven't kept up with the different manifestations of clang on Windows lately. My point is simply that a version of clang for Windows has existed targeting VC++ which specifically 'emulates' the non-standard VC++ preprocessor. The non-standard VC++ preprocessor gets special treatment in quite a few cases in Boost PP and Boost VMD or else it will simply fail using much of those libraries. Therefore if versions of clang which 'emulate' the VC++ preprocessor attempt to use Boost PP and Boost VMD it too will fail in a large number of cases. I have no idea whether AFIO v2 uses Boost PP. I am perfectly willing to set clang targeting VC++ on Windows which 'emulates' the VC++ preprocessor to essentially act like the VC++ preprocessor in Boost PP and Boost VMD if I can unequivocally identify this version at preprocessor time. Then if it fails to compile parts of Boost PP and Boost VMD it will be a problem for the clang developers to solve, because I have no interest in trying to workaround such problems in Boost PP and Boost VMD for yet another non-conformant C++ preprocessor. I also want to point out that the normal standard conformant clang preprocessor is different enough from the clang 'emulation' of VC++ preprocessor that it is imperative to identify each one or else Boost PP and Boost VMD will not work in large parts of their implementation. Of course if a Boost library does not use Boost PP ( or Boost VMD which no Boost libraries of which I am aware currently use ), or uses a very small part of Boost PP not affected by the many VC++ workarounds in Boost PP, it is possible it will not run into problems with clang 'emulating' VC++. But I would not count on such lucky behavior.