[llvm-bugs] [Bug 34243] New: Clang should default to -fms-compatibility-version=19.11

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=34243

            Bug ID: 34243
           Summary: Clang should default to
                    -fms-compatibility-version=19.11
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: sfinae at hotmail.com
                CC: llvm-bugs at lists.llvm.org

https://github.com/llvm-mirror/clang/blob/948113089e026114699a517bacf0a85987f6a5c8/lib/Driver/ToolChains/MSVC.cpp#L1232
is where Clang defaults to imitating MSVC 18.00 (VS 2013's toolset). That's
seriously old (Clang 3.3 was released in 2013). Perhaps now would be a good
time to update this default to MSVC 19.11 (VS 2017 15.3's toolset), and
establish a policy of updating this default to the latest released MSVC
toolset.

Additionally,
https://github.com/llvm-mirror/clang/blob/7cf32f297706a8e2c9d60c258cdd3d28860b9cf1/lib/Driver/ToolChains/Clang.cpp#L3842
says that "-fno-delayed-template-parsing is default, except for Windows where
MSVC STL needs it." MSVC's STL is now two-phase clean, validated by Clang
itself, and has been for quite some time (previously we used EDG to validate
this, and fixed many issues over the years). While the MSVC compiler is still
migrating to two-phase (currently there's partial support controlled by a
compiler option which isn't the default yet), our STL is ready. Note that other
libraries (ATL etc.) are still undergoing two-phase cleaning, so I don't know
if Clang users tend to expect compatibility or conformance.

Similarly, MSVC's STL is now -fno-ms-compatibility clean, although not all MS
libraries are. (We're trying to purge all unnecessary non-Standard code,
including in the WinSDK.)

-- 
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/20170819/342837dd/attachment.html>