[llvm-bugs] [Bug 38478] New: Clang 7.0.0 RC1 -fno-ms-compatibility rejects Windows.h

[via llvm-bugs]

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

            Bug ID: 38478
           Summary: Clang 7.0.0 RC1 -fno-ms-compatibility rejects
                    Windows.h
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: sfinae at hotmail.com
                CC: llvm-bugs at lists.llvm.org

I use -fno-ms-compatibility to verify that MSVC's STL uses conformant code
whenever possible. Between Clang 6.0.0 and 7.0.0 RC1, this started rejecting
Windows.h due to nonconformant enumerators:

C:\Temp>type kitty.cpp
#include <Windows.h>

C:\Temp>clang-cl -m32 -v
clang version 7.0.0 (tags/RELEASE_700/rc1)
Target: i386-pc-windows-msvc
Thread model: posix
InstalledDir: S:\msvc\src\vctools\NonShip\ClangLLVM\bin

C:\Temp>clang-cl -m32 /EHsc /nologo /W4 /c -fno-ms-compatibility kitty.cpp
In file included from kitty.cpp:1:
In file included from
S:\msvc\src\ExternalApis\Windows\10\sdk\inc\Windows.h:173:
S:\msvc\src\ExternalApis\Windows\10\sdk\inc\wingdi.h(2819,5):  error:
enumerator value is not representable in the
      underlying type 'int'
    DISPLAYCONFIG_OUTPUT_TECHNOLOGY_INTERNAL                = 0x80000000,
    ^
[...]

I've reported this to the WinSDK team, but I still need to unblock my testing
in the meantime. Can some way be added to request the strictness of
-fno-ms-compatibility, but without rejecting Windows.h like this?

Possibilities:

* A fine-grained option, so I could compile with -fno-ms-compatibility
-fms-compatibility-enum-value to request strictness for everything except these
enum values. 

* I observe that -Wmicrosoft contains the fine-grained warning
-Wmicrosoft-enum-value for this case. Instead of introducing a new fine-grained
option, if -fno-ms-compatibility -Wno-microsoft-enum-value avoided this error,
that would be equally good for me. Perhaps better, because then I could wrap
Windows.h in

#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wmicrosoft-enum-value"
#pragma clang diagnostic pop

and retain the enum strictness for the rest of our code.

* Go back to doing whatever Clang 6 did, which was presumably to consider this
enum behavior part of ms-extensions instead of ms-compatibility (but allowing
-Wmicrosoft to warn about it).

-- 
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/20180808/2a848fec/attachment.html>