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

[Edward Diener]

On 7/12/2014 6:05 PM, Tim Toomay wrote:
> Dump the hyperbole.  It is counter productive.

I apologized for getting too emotional. However there is no hyperbole in 
the mere fact that when you use the VC++ preprocessor, or use clang-cl 
emulating some number of VC++'s preprocessor bugs, you may be producing 
preprocessor errors on perfectly valid preprocessor macros or, what is 
worse, you may be silently producing incorrect output from perfectly 
valid preprocessing macros.

This is why I am suggesting that while I understand that clang-cl needs 
to emulate VC++ preprocessor bugs in whatever respects in order to 
compile Microsoft header files it should do everything possible to 
implement C++ standard preprocessing for all other non-Microsoft header 
files with macros.

Surely no one wants to have a buggy preprocessor produce false errors or 
invalid output if it can be avoided.

The fact that the VC++ preprocessor can silently produce invalid macro 
output has never been acknowledged by Microsoft any more than the fact 
that their preprocessor does not follow the C++ standard. While the use 
cases where the VC++ preprocessor can cause errors or invalid output may 
be very small given the ways in which the large majority of C++ code use 
C++ macros, that use case does exist. Since I have worked extensively 
with such a library ( Boost PP ) and have developed another macro 
library ( VMD ), using some advanced preprocessor metaprogramming 
techniques which illustrate the bugs in the VC++ compiler, I am aware of 
their existence and the difficulty of writing such macro constructs with 
the idea of getting them to work with VC++'s non-standard preprocessor.

I am glad, as you say, that for "rudimentary C++" the preprocessing bugs 
of VC++, or clang-cl's emulation of those bugs, will not affect you and 
even a majority of C++ programmers. But there are some end-users who use 
and/or write macros who will be affected ( as in many Boost libraries ). 
It is for them I feel impelled to speak.

> I am in the camp of people that want to move their msvc code to other
> realms.  I am chiming in for political reasons.  Our stuff is
> rudimentary C++ and we use as little of the host os abuse as possible.
> But you can barely do anything without interfacing to some important
> libraries.
>
> It seems obvious that the minimum functionality is that you can compile
> and debug processes with clang that will run on windows. That to me
> implies being able to _LINK_ with platform libraries. To some extent
> that means you have to be able to digest their macros.  But that is not
> the same as a wholesale emulation.  I see no way around doing at least
> that much emulation.
>
> Thanks!
>
> On 7/10/2014 2:59 PM,
> cfe-dev-request at cs.uiuc.edu wrote:
>> Send cfe-dev mailing list submissions to
>>     cfe-dev at cs.uiuc.edu
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>     http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>> or, via email, send a message with subject or body 'help' to
>>     cfe-dev-request at cs.uiuc.edu
>>
>> You can reach the person managing the list at
>>     cfe-dev-owner at cs.uiuc.edu
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of cfe-dev digest..."
>>
>>
>> Today's Topics:
>>
>>     1. Re: Clang-cl.exe and the VC++ preprocessor (Chandler Carruth)
>>     2. Re: Clang-cl.exe and the VC++ preprocessor (Edward Diener)
>>     3. Re: Clang-cl.exe and the VC++ preprocessor (Aaron Ballman)
>>     4. Re: Clang-cl.exe and the VC++ preprocessor (Edward Diener)
>>     5. Re: Clang-cl.exe and the VC++ preprocessor (Daniel James)
>>     6. Re: Clang-cl.exe and the VC++ preprocessor (Nico Weber)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Thu, 10 Jul 2014 13:45:59 -0700
>> From: Chandler Carruth
>> <chandlerc at google.com>
>> To: Nico Weber <thakis at chromium.org>
>> Cc: clang-dev Developers
>> <cfe-dev at cs.uiuc.edu>,    Edward Diener
>>     <eldlistmailingz at tropicsoft.com>
>> Subject: Re: [cfe-dev] Clang-cl.exe and the VC++ preprocessor
>> Message-ID:
>>     <CAGCO0Kg=PQKfMgH_Qdiwo_+A5aimZZjYKDed1TiNqFoouWzntg at mail.gmail.com>
>>
>> Content-Type: text/plain; charset="utf-8"
>>
>> On Thu, Jul 10, 2014 at 1:43 PM, Nico Weber
>> <thakis at chromium.org> wrote:
>>
>>> Shouldn't that just be _MSC_VER?
>>
>> It might be desirable to be able to compile some Windows system headers
>> (that rely on _MSC_VER, but not on all of the crazy in the bug-for-bug
>> compatibility) in this mode.
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> <http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20140710/0bb5f01a/attachment-0001.html>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Thu, 10 Jul 2014 16:56:54 -0400
>> From: Edward Diener
>> <eldlistmailingz at tropicsoft.com>
>> To: cfe-dev at cs.uiuc.edu
>> Subject: Re: [cfe-dev] Clang-cl.exe and the VC++ preprocessor
>> Message-ID: <lpmumn$37p$1 at ger.gmane.org>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> On 7/10/2014 4:08 PM, Aaron Ballman wrote:
>>> On Thu, Jul 10, 2014 at 3: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.
>>> I have the opposite view. Having an MSVC-compatible preprocessor is an
>>> excellent thing for interoperability on the platform.
>> Am MSVC-compatible preprocessor is a broken preprocessor. How can this
>> be an excellent thing ? If the idea is to emulate VC++ in every respect,
>> there is no point in using clang-cl. Really !
>>
>>> It increases the
>>> likelihood of adopting clang as a native toolset on Windows, and
>>> reduces the barrier to entry, because it allows me to take code which
>>> compiles with MSVC and instead run it through clang.
>> Again there is no point in using clang if you are just going to emulate
>> VC++. Is not the idea to produce a standard conforming compiler for
>> people to use on their VC++ code which is better and cleaner than VC++
>> with all its bugs.
>>
>>> This functionality is behind a flag (-fms-compatibility), and it would
>>> be a step backwards to say "please turn on compatibility with MSVC,
>>> except for the preprocessor" when that flag is enabled. It would also
>>> prevent using MSVC's STL (IIRC, <type_traits> relies on this behavior
>>> in MSVC 2012 due to the compiler's lack of support for variadic
>>> templates).
>>>
>>> I would not be opposed to a more fine-grained flag that allowed you to
>>> disable the quirks for the processor when -fms-compatibility is turned
>>> on, akin to -fno-delayed-template-parsing.
>> So you want a default that produces the same bugs as VC++ and only a
>> switch will produce a standard conforming compiler. I cannot tell you
>> how amazing I find that and how wrong that is.
>>
>> Honestly if that is the case, aka "let's just create a completely
>> compatible compiler with VC++", I haven't the faintest idea why clang
>> developers would have spent a second of their time doing that since
>> anybody can use VC++ instead.
>>
>>> ~Aaron
>>>
>>
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Thu, 10 Jul 2014 17:11:55 -0400
>> From: Aaron Ballman <aaron at aaronballman.com>
>> To: Edward Diener
>> <eldlistmailingz at tropicsoft.com>
>> Cc: cfe-dev Developers <cfe-dev at cs.uiuc.edu>
>> Subject: Re: [cfe-dev] Clang-cl.exe and the VC++ preprocessor
>> Message-ID:
>>     <CAAt6xTt1bzeDpfdq8CYOb3bq4pZA8R9cDQ1x-pZ-CA7gM3XY-Q at mail.gmail.com>
>>
>> Content-Type: text/plain; charset=UTF-8
>>
>> On Thu, Jul 10, 2014 at 4:56 PM, Edward Diener
>> <eldlistmailingz at tropicsoft.com> wrote:
>>> On 7/10/2014 4:08 PM, Aaron Ballman wrote:
>>>> On Thu, Jul 10, 2014 at 3: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.
>>>>
>>>> I have the opposite view. Having an MSVC-compatible preprocessor is an
>>>> excellent thing for interoperability on the platform.
>>>
>>> Am MSVC-compatible preprocessor is a broken preprocessor. How can
>>> this be an
>>> excellent thing ? If the idea is to emulate VC++ in every respect,
>>> there is
>>> no point in using clang-cl. Really !
>>>
>>>
>>>> It increases the
>>>> likelihood of adopting clang as a native toolset on Windows, and
>>>> reduces the barrier to entry, because it allows me to take code which
>>>> compiles with MSVC and instead run it through clang.
>>>
>>> Again there is no point in using clang if you are just going to emulate
>>> VC++. Is not the idea to produce a standard conforming compiler for
>>> people
>>> to use on their VC++ code which is better and cleaner than VC++ with
>>> all its
>>> bugs.
>>>
>>>
>>>> This functionality is behind a flag (-fms-compatibility), and it would
>>>> be a step backwards to say "please turn on compatibility with MSVC,
>>>> except for the preprocessor" when that flag is enabled. It would also
>>>> prevent using MSVC's STL (IIRC, <type_traits> relies on this behavior
>>>> in MSVC 2012 due to the compiler's lack of support for variadic
>>>> templates).
>>>>
>>>> I would not be opposed to a more fine-grained flag that allowed you to
>>>> disable the quirks for the processor when -fms-compatibility is turned
>>>> on, akin to -fno-delayed-template-parsing.
>>>
>>> So you want a default that produces the same bugs as VC++ and only a
>>> switch
>>> will produce a standard conforming compiler. I cannot tell you how
>>> amazing I
>>> find that and how wrong that is.
>>>
>>> Honestly if that is the case, aka "let's just create a completely
>>> compatible
>>> compiler with VC++", I haven't the faintest idea why clang developers
>>> would
>>> have spent a second of their time doing that since anybody can use VC++
>>> instead.
>> Being able to migrate large, existing code bases off of MSVC requires
>> compatibility with MSVC in practice, which is what drives me (and
>> likely quite a few others) to contribute to clang.
>>
>> As Chandler has pointed out, this is a balancing act. We try to avoid
>> adding nonconforming changes to the compiler simply to be bug-for-bug
>> compatible with another compiler. But we don't shy away from adding
>> them when there are valid reasons to do so. This particular
>> compatibility piece is in place in order to migrate code using MSVC
>> 2012's <type_traits> header. We add others to be compatible with gcc
>> from time to time as well.
>>
>> ~Aaron
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Thu, 10 Jul 2014 17:25:29 -0400
>> From: Edward Diener
>> <eldlistmailingz at tropicsoft.com>
>> To: cfe-dev at cs.uiuc.edu
>> Subject: Re: [cfe-dev] Clang-cl.exe and the VC++ preprocessor
>> Message-ID: <lpn0cb$mqu$1 at ger.gmane.org>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> 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.
>>
>>
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Thu, 10 Jul 2014 22:59:14 +0100
>> From: Daniel James <daniel at calamity.org.uk>
>> To: Chandler Carruth <chandlerc at google.com>
>> Cc: clang-dev Developers
>> <cfe-dev at cs.uiuc.edu>,    Edward Diener
>>     <eldlistmailingz at tropicsoft.com>
>> Subject: Re: [cfe-dev] Clang-cl.exe and the VC++ preprocessor
>> Message-ID:
>>     <CAHOE3ydADxaKSGL4Cy6ft0Wda2kBFxRFioHu+t_9tRnuhUSaFw at mail.gmail.com>
>>
>> Content-Type: text/plain; charset=UTF-8
>>
>> On 10 July 2014 21:14, Chandler Carruth
>> <chandlerc at google.com> wrote:
>>> 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.
>> Since much of Boost is header only, the user controls the compile
>> flags, so that's not possible.
>>
>>
>> ------------------------------
>>
>> Message: 6
>> Date: Thu, 10 Jul 2014 14:59:44 -0700
>> From: Nico Weber <thakis at chromium.org>
>> To: Edward Diener
>> <eldlistmailingz at tropicsoft.com>
>> Cc: "cfe-dev at cs.uiuc.edu Developers"
>> <cfe-dev at cs.uiuc.edu>
>> Subject: Re: [cfe-dev] Clang-cl.exe and the VC++ preprocessor
>> Message-ID:
>>     <CAMGbLiHbtwcLO2BRHLdmbC0vQYty6qPNa5D3-tdUDh8E0sH7Kw at mail.gmail.com>
>>
>> Content-Type: text/plain; charset="utf-8"
>>
>> 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.cs.uiuc.edu/pipermail/cfe-dev/attachments/20140710/170251a8/attachment.html>
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>> End of cfe-dev Digest, Vol 85, Issue 46
>> ***************************************
>>
>>
>>
>