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

[Edward Diener]

On 7/10/2014 4:14 PM, Chandler Carruth wrote:
>
> On Thu, Jul 10, 2014 at 12:55 PM, Edward Diener
> <eldlistmailingz at tropicsoft.com
> <mailto:eldlistmailingz at tropicsoft.com>> wrote:
>
>     I have been told, via my bug report on a preprocessor error in the
>     latest version of clang-cl.exe, that clang-cl.exe is trying to
>     emulate at least some of the bugs of the VC++ preprocessor.
>
>     NO ! Please do not do that.
>
>     I know, from having worked on variadic macros in Boost PP and having
>     created my own variadic macro data library, how broken the VC++
>     preprocessor is when it comes to preprocessor metaprogramming. Paul
>     Mensonides, the creator of Boost PP and an exceptional expert on the
>     C++ preprocessor, also knows and has bemoaned countless times how
>     difficult it is to do preprocessor metaprogramming if one has to
>     deal with the VC++ preprocessor. Not only will clang-cl.exe's
>     emulation of the brokeness of the VC++ preprocessor set back further
>     efforts in metaprogramming preprocessor code and libraries but there
>     is absolutely no chance, if it means anything to clang-cl
>     developers, that any effort will be made to accomodate clang-cl's
>     preprocessor bugs into Boost PP ( or my own variadic macro data
>     library ).
>
>     This is completely the wrong direction for clang-cl to go. Please
>     stop and only consider producing as close to as possible a 100% C++
>     conformant preprocessor, as the rest of clang no doubt has as its goal.
>
>
> So, I feel like we're between a rock and a hard place here.
>
> At a fundamental level there are bugs we need to be bug-for-bug
> compatible with because there is large amounts of existing code in the
> wild relying on those bugs.
>
> At the same time, I'm quite sympathetic to not wanting to make things
> less conforming.

In the case of the VC++ preprocessor you really have to be a masochist, 
and someone with little pride in correct C++, to want to emulate the 
bugs there.

>
> But I don't see an easy way to have both. Here are my suggestions, but
> none of them are great:
>
> 1) Make sure that any bug-compatibility is inspired by actual code
> relying on the bug. I suspect it is in this case, but its always good to
> check.

This is a fool's errand, sir. You have no idea of all the "existing code 
in the wild". Do you really think because someone has written a macro 
that relies on the non-conformance of the VC++ preprocessor that it is 
clang-cl's responsibility to reproduce that same preprocessing bug ? Or 
even a theoretical someone.

> 2) It may be desirable for Boost (and Boost users) to opt into a more
> strict mode. I get the flags backwards all the time (Reid or someone
> else will correct me) but we have two flags to control compatibility:
> one for essentially conforming (or at least not horrible broken)
> extensions, and another for bug-for-bug compatibility. I think the
> latter is '-fms-compatibility' while the former is '-fms-extensions',
> but again, i get them backwards. Anyways, perhaps Boost would want to
> use '-fno-ms-compatibility' where possible to get a more conforming
> implementation.

I do not ultimately control the Boost PP library, Paul Mensonides does 
although I am a contributor, but I can almost guarantee you that he has 
no inclination, and I know I have none, to make any changes to 
accomodate clang-cl's emulation of VC++ preprocessor bugs no matter what 
compatibility options and emulation of whatever VC++ preprocessor bugs 
clang-cl wants to promote. And if others are willing to go into that 
Boost PP code and hack around with it given the ridiculousness of 
clang-cl attempting to emulate the brokeness of the VC++ preprocessor in 
whatever respects, I wish them the best of luck through their 
hair-pulling and tears.

>
> 3) I think we should then make sure we expose macros you can use to
> detect the bug-for-bug compat mode, and use the (horrible) cl.exe
> implementations of things like Boost PP, even though the host compiler
> is Clang.
>
> Does this make sense?

Not to me. The only thing that makes sense, quite honestly, is that 
clang, and clang-cl, produce a C++ standard conforming preprocessor. 
Furthermore there is no way you will ever get Microsoft to fix their 
broken preprocessor if you think that emulating their own preprocessing 
bugs is the way to go. If you want to make a switch in clang-cl to 
produce a standard conforming preprocessor, rather than have it be the 
default, my message to anyone using Boost will be simply that without 
this switch there is no point in using Boost in their code. Of course if 
this does not matter they can do what they want.

Please, please reconsider the notion that you can produce a compiler 
worthy of clang, to be used by VC++ programmers, by reproducing VC++ 
preprocessor bugs. This is a realy bad path to take.