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

[Chandler Carruth]

On Thu, Jul 10, 2014 at 12: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.
>

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.

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.

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.

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140710/ecbe21d7/attachment.html>