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

[Nico Weber]

On Thu, Jul 10, 2014 at 2:25 PM, Edward Diener <
eldlistmailingz at tropicsoft.com> wrote:

> 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.


I don't have much of an opinion on this topic (as long as clang-cl can
parse MS headers), but please drop the hyperbolic language and stick to
technical arguments.


>
>
>
>> 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.
>
>
> _______________________________________________
> 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/170251a8/attachment.html>