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

[Aaron Ballman]

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