https://llvm.org/bugs/show_bug.cgi?id=27169
Bug ID: 27169
Summary: Make MSVC preprocessor emulation optional in MSVC
targets
Product: clang
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P
Component: Frontend
Assignee: unassignedclangb...@nondot.org
Reporter: s_bugzi...@nedprod.com
CC: llvm-bugs@lists.llvm.org
Classification: Unclassified
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.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
