Clang and MSVC11 headers

To what extent does clang try to make itself compatible with MSVC headers, for
use of clang on Windows? I’ve recently been trying to use clang on Windows
along with the MSVC11 headers, and clang fails to compile the macro magic that
is used to emulate variadic templates. Upon further investigation, this is
because the macros themselves are incorrect, but work in MSVC due to a bug in

the preprocessor. I’ve submitted a bug report [1], but this is apparently a
known issue, and I’m not optimistic about it ever getting fixed.

What does this mean for us few clang-on-windows users? Are the MSVC11 headers a
lost cause, or could clang implement some sort of MSVC preprocessor
compatibility mode?

[1] https://connect.microsoft.com/VisualStudio/feedback/details/785846

  • Leszek

It's a known issue (need to file a PR).

IIUC, it has to do with pre-processor comma expansion, but I could be
wrong. Joao posted a patch:
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-April/029266.html

I've mostly focused on building with MSVC 2010 headers, so I haven't
had to deal with this.

Can we go forward with the preprocessor patch? I wasn't around for
the revert, so I don't have any context. Is it just a question of
getting a review?

It's a known issue (need to file a PR).

IIUC, it has to do with pre-processor comma expansion, but I could be
wrong. Joao posted a patch:
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-April/029266.html

I've mostly focused on building with MSVC 2010 headers, so I haven't
had to deal with this.

Can we go forward with the preprocessor patch? I wasn't around for
the revert, so I don't have any context. Is it just a question of
getting a review?

I think I reverted it because it broke compiling the MSVS2010 headers.

…no, it broke gtest. http://llvm.org/bugs/show_bug.cgi?id=13924 /
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120924/065029.html

Nico

Clang tries to be msvc compatible (-fms-comaptibilty switch) by
implementing non standard behavior (or bugs) that are absolutely
necessary to parse standard library/platform sdk. But windows support
is generally lacking.

Oddly enough, that test passes using MSVC.

I suspect this might be because the given patch only partially emulates
MSVC behaviour; that is, it has commas as a special case, whereas I think
the problem is something along the lines of the expanded macro parameter
not being re-tokenised, commas, parens and all. If there is indeed such a
retokenisation step, perhaps MS compatibility mode could skip it? I don't
know nearly enough about Clang internals, or indeed the C preprocessor, to
submit a patch, but that's my "layman's analysis".

It would be nice to get this finally fixed as it is a very annoying bug that makes using Clang on Windows with MSVC11 impossible without custom patches.

My patch is probably an hack, and I don’t know enough about the preprocessor works to understand how to do the correct fix without spending a lot of time researching it. Your explanation sounds interesting though.

Would enabling my patch only for MSVC/system headers be an acceptable workaround for now?

Actually, having taken another look at your patch, it looks like it could almost do the job. Rather than just ignoring all expanded commas, I’ve made a change where all freshly expanded tokens are ignored by the lexer when first passed over, which seems to be doing the job so far. The below patch is a quick hack that doesn’t check if we’re running in ms-compatibility mode yet, still testing if it’s actually ms-compatibile.

Still a hack, but I suspect a non-hack ms-compatibilty for this would involve some major reshuffling of the lexer.

Does it fix regression problem Nico found?

It does, but now it looks like it breaks
test/Preprocessor/macro_rescan_varargs.h. This might be because MSVC might
treat the commas expanded from __VA_ARGS__ differently to commas expanded
from a normal macro.