[llvm-bugs] [Bug 27169] New: Make MSVC preprocessor emulation optional in MSVC targets

[via llvm-bugs]

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: unassignedclangbugs at nondot.org
          Reporter: s_bugzilla at nedprod.com
                CC: llvm-bugs at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160331/76d8cc7a/attachment.html>