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

[Aaron Ballman]

On Thu, Jul 10, 2014 at 6:54 PM, Edward Diener
<eldlistmailingz at tropicsoft.com> wrote:
> 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 ?

Basically anything involving the _VARIADIC_EXPAND_XXX macros they used
in place of variadic templates.

http://llvm.org/bugs/show_bug.cgi?id=14981

~Aaron