Make MSVC preprocessor emulation optional in MSVC targets

[Quuxplusone]

Bugzilla Link	PR27169
Status	NEW
Importance	P enhancement
Reported by	Niall Douglas (s_bugzilla@nedprod.com)
Reported on	2016-03-31 14:28:08 -0700
Last modified on	2016-04-15 17:21:28 -0700
Version	unspecified
Hardware	All All
CC	heavenandhell171@gmail.com, llvm-bugs@lists.llvm.org, marci_r@web.de
Fixed by commit(s)
Attachments
Blocks
Blocked by
See also	PR27380

Relevant discussions on this topic on cfe-dev:

* http://clang-developers.42468.n3.nabble.com/Clang-cl-exe-and-the-VC-
preprocessor-td4040453.html

* http://clang-developers.42468.n3.nabble.com/Emulation-of-VC-preprocessor-
td4050767.html

Right now if clang is targeting the MSVC ABI and _MSC_VER is defined on, the
MSVC preprocessor's special behaviours are partially emulated. Historically
this was especially to enable Windows system headers to be correctly parsed,
however as of Visual Studio 2015 Update 2 RC it looks as if most, if not all,
of the Windows system header dependencies on the broken MSVC preprocessor have
been fixed [1].

This is probably because of the MSVC standards conformance roadmap published at
https://blogs.msdn.microsoft.com/somasegar/2014/06/03/visual-studio-14-ctp/
which shows correct C99 preprocessor behaviour as being roadmapped after
Expression SFINAE which sees an enormous improvement in VS2015 Update 2, so
fixing the preprocessor is likely their next big work item.

Can I therefore ask for the following:

1. When compiling using clang-cl.exe, we get the broken MSVC processor
emulation if _MSC_VER is young enough, but when compiling using clang.exe with
a -msvc target we do NOT get the broken MSVC processor emulation unless -fms-
compatibility is enabled or a new flag -fms-preprocessor is enabled. If this is
felt to break too much backwards compatibility, one could make this new
behaviour dependent on the value of -fms-compatibility-version, but I'd really
prefer if clang.exe were as standards conforming as possible, especially as
cl.exe is heading the same way soon.

2. A new #pragma is added to control the preprocessor. #pragma
msvc_pp_compat(push|pop|on|off) was suggested in the threads above. I'd suggest
#pragma ms-preprocessor instead personally.

3. The ability to turn push, pop, on and off -fms-compatibility and -fdelayed-
template-parsing via #pragma would also be very helpful.

4. I've noticed that sometimes LLVM clang does not define __clang__ AND
_MSC_VER simultaneously, whereas C1 clang which uses the Microsoft backend does
define both simultaneously. It really would be super useful if you defined both
so code works on both clang's equally, even if some code may break due to bad
macro logic regarding either/or MSVC vs clang.

I appreciate the changes above may break some users of clang with a MSVC
target. However better to break them now when the userbase is so small rather
than later when C1 clang becomes the primary C++ compiler for many Visual
Studio 201x users.

Finally, my congratulations to everyone @ clang for getting MSVC support
working so well. I am now _regularly_ building my personal Boost libraries from
within Visual Studio 2015 Update 2 RC using both C1 clang and LLVM clang and it
all "just works" even with -fms-compatibility=no, which is an enormous
achievement. Thank you.

Niall

[1]: This claim is supported purely through me running a diff of the VS2015
Update 2 system headers against previous editions. There appears to be
substantial repair work done to make C1 clang happy in a least forgiving
configuration. Other than by inspection, I provide no other supporting evidence
for my claim, but someone from Microsoft could probably just say if asked.

[Quuxplusone]

> 4. I've noticed that sometimes LLVM clang does not define __clang__ AND
_MSC_VER simultaneously, whereas C1 clang which uses the Microsoft backend does
define both simultaneously. It really would be super useful if you defined both
so code works on both clang's equally, even if some code may break due to bad
macro logic regarding either/or MSVC vs clang.

Sigh. I submitted this bug report when tired. Of course I meant *C2* clang, not
C1 clang throughout the description. I also found a very useful table listing
the macro settings for all of clang variants at
https://blogs.msdn.microsoft.com/vcblog/2015/12/04/clang-with-microsoft-codegen-
in-vs-2015-update-1/, which explains everything about the macro weirdness.

Based on that table I will add a request no. 5 though:

5. Please stop defining __GNUC__ et al when the ABI target is MSVC, even if -
fms-compatibility=no. Only the Microsoft macros _MSC_VER et al should be
defined, and the __clang__ et al ones. Claiming GNU C compatibility makes no
sense whatsoever for a MSVC ABI and MSVCRT targeted build and more importantly,
causes significant breakage for portable C and C++ programs who assume #if
defined(_WIN32) && defined(__GNUC__) means Mingw32 headers and runtime and the
Itanium ABI. As indeed did my code, until last night.

Niall