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

[Edward Diener]

On 7/10/2014 5:11 PM, Aaron Ballman wrote:
> 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.

The problem with the VC++ preprocessor bugs is that there are many 
situations where VC++ simply does not work correctly doing macro 
expansion. Even figuring out why VC++ is incorrectly doing macro 
expansion is next to impossible unless you have their source code for 
their preprocessor, which I have my doubts that clang has. So now 
clang-cl wants to emulate, let's say, some of those buggy preprocessor 
macro expansions which VC++ does but clearly not all of them since it is 
impossible to figure out all of them. This now creates one more dialect 
of a buggy preprocessor for preprocessor metaprogrammers to deal with.

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

Would you please point out to me what in the VC12 <type_traits> does not 
compile with a standard conforming C++ preprocessor ?