[cfe-dev] cfe-dev Digest, Vol 85, Issue 46
Tim Toomay
toomayt at toomaytech.com
Sat Jul 12 15:02:42 PDT 2014
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.
Dump the hyperbole. It is counter productive.
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
> ***************************************
>
>
>
--
Tim Toomay
Toomay Technologies Inc
www.ToomayTech.com
*****
NOTICE OF CONFIDENTIALITY: The information contained in this e-mail and attachment(s), if any, is legally protected pursuant to the Electronic Communications Privacy Act, 18 U.S.C. 2510, et seq., inter alia, and may contain privileged and confidential information. This communication is intended only for the use of each individual named above. If you know, or have any reason to believe, that you are not an intended recipient, you are hereby notified that any dissemination or duplication of this e-mail is prohibited. There is and shall be no waiver of any privilege or confidence by your receipt of this transmission. If you know or have any reason to believe that you received this e-mail in error, please immediately notify us by e-mail or collect telephone call.
More information about the cfe-dev
mailing list