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

[Matt Calabrese]

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

I've done a lot of preprocessor metaprogramming in the past and I am
extremely sympathetic here. A few years ago, I think in in the context of
trying to get Paul to get Chaos into the Boost review queue (one of several
times), one of his reasons for not doing so was because he did not want to
support broken preprocessors -- especially Microsoft. It still should get
in anyway, but that's another story.

I've never implemented a C preprocessor (thankfully), but one thing that
I've wondered about that may actually be feasible and may allow for a way
forward, is to have a pragma that allows you to toggle between the buggy
MS-style preprocessor and a compliant one. The idea is that when any macros
are defined while the buggy mode is on, those macros internally behave as
they would if defined in Microsoft's broken implementation whenever they
are expanded. Similarly, if the toggle is the other way (specifying
compliance), then everything works as expected in a compliant preprocessor
implementation. In other words, preprocessor definitions, depending on the
state of the toggle at the time they are defined, internally behave
differently upon expansion. If a compliant-mode definition invokes a
non-compliant macro, the MS-emulation only happens internal to the broken
macro's expansion. Similar-but-opposite behavior would be expected when the
composition of the macros is flipped (note that this would be less
important to support than the latter). Hypothetically there could also be a
way at the command-line to specify that certain include paths should always
have this broken preprocessor option on for the duration of the include,
whereas by default, other files do not (the default could be switched, but
I think this would be ideal).

The idea of all of this is that in the vast majority of cases (I have no
numbers on this, but I think it's a reasonable hunch) the only reason
people care about MS preprocessor emulation is because they need to
preprocess MS headers or other libraries that they, themselves, have not
written. I'd be surprised if a lot of people had preprocessor-heavy code
that is difficult to fix, but if they did, they could opt-in for the broken
preprocessor if they so chose. At the very least, libraries like
Boost.Preprocessor could use the pragma so that they don't need to
bend-over-backwards to try to support another implementation (clang's
preprocessor is already awesome in this respect).

Again, I have not thought through this very deeply and do not have the
experience here necessary to say whether this is actually feasible or not,
but I present it as an option hoping that someone out there who does have
the experience can at least consider it. The whole point of this is that
emulating MS's preprocessor bugs allows "proper" preprocessing of
broken-but-important headers and so its importance cannot be stressed
enough. On the other side, producing a sort-of-like-MS preprocessor that
everyone is stuck with just because of Windows headers is itself a horror.
I'm not entirely convinced that we can't somehow have our cake and eat it
too in this particular instance.

-- 
-Matt Calabrese
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140710/871e8fb6/attachment.html>