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

[Edward Diener]

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
>