[cfe-dev] Clang-cl.exe and the VC++ preprocessor

[Richard Smith]

On Fri, Jul 11, 2014 at 8:32 AM, Jonathan 'Rynn' Sauer <
jonathan.sauer at gmx.de> wrote:

> Hello,
>
> > Also it's worth pointing out that the idea is not to emulate VC++ in
> every respect.  Only in every respect where not doing so will break vast
> amounts of code.  There are plenty of places where not emulating VC++ will
> *fix* vasts amounts of code.  I imagine the goal is to depart with VC++ in
> those respects.
> >
> > There are examples where not emulating VC++'s bugs means **we can't even
> include standard windows headers**.  Surely we agree that a Windows
> compiler that cannot include <windows.h> would not be particularly useful.
>
> Could it be an option to limit the emulation of VC++'s preprocessor to
> system headers and macros defined
> there, similar to how clang suppresses warnings in these cases?


I don't think so, no. Clang defines _MSC_VER, so code that has separate
preprocessor magic for cl.exe versus everything else should use the cl.exe
path. As a result, we'd break such code if we didn't act like cl.exe.


In boost's case, the problem is that


http://www.boost.org/doc/libs/1_55_0/boost/preprocessor/seq/detail/binary_transform.hpp

does not take the MSVC-preprocessor-compatible code path, because:

  http://www.boost.org/doc/libs/1_55_0/boost/preprocessor/config/config.hpp

... explicitly shoots itself in the foot:

#    if defined _MSC_VER && _MSC_VER >= 1400 && !(defined __EDG__ ||
defined __GCCXML__ || defined __CUDACC__ || defined __PATHSCALE__ ||
defined __clang__ || defined __DMC__ || defined __CODEGEARC__ || defined
__BORLANDC__ || defined __MWERKS__ || defined __SUNPRO_CC || defined
__HP_aCC || defined __MRC__ || defined __SC__ || defined __IBMCPP__ ||
defined __PGI)
#        define BOOST_PP_VARIADICS_MSVC 1
#    endif

I'm not sure what that list of compilers is for (if _MSC_VER is defined,
why don't you assume the compiler acts like MSC?), but removing "|| defined
__clang__" from the list should fix the issue.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140711/6e5dc4b1/attachment.html>