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

[Nico Weber]

On Thu, Jul 10, 2014 at 1:14 PM, Chandler Carruth <chandlerc at google.com>
wrote:

>
> On Thu, Jul 10, 2014 at 12:55 PM, Edward Diener <
> 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.
>
> 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.
>
> 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.
>
> 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.
>

Shouldn't that just be _MSC_VER?


>
> Does this make sense?
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140710/d8fd3f84/attachment.html>