Come up with story for Wmicrosoft-enum-value |
||||||
Issue descriptionSplit off from bug 504657 . -Wmicrosoft-enum-value fires all over the place if not suppressed, with "enumerator value is not representable in the underlying type 'int'" for enums that store e.g. DWORDS (`enum { TLS_KEY_OUT_OF_INDEXES = TLS_OUT_OF_INDEXES };`) or literals with the high bit set (`MD_NTSTATUS_WIN_STATUS_DEVICE_ALREADY_ATTACHED = 0xC0000038`). This isn't a useful warning currently since it fires all over the place in system headers, and all that code does work. One idea is to instead warn when that enum value is compared to 0, since that will have different behavior on MS and non-MS. I tried implementing this a few months ago, but we don't remember if a literal was sign-converted in the AST. Maybe we should remove the current warning from clang for now, since it's not super useful that every project has to suppress it.
,
Jun 22 2016
Here's my wip.patch from a while ago. `// XXX this ruins our life` marks the spot where the ast is currently lossy.
,
May 4 2017
,
Jun 23 2017
https://codereview.chromium.org/2954703002 removed Wno-microsoft-enum-value, since that warning is now disabled by default. So let's close this bug here. I filed https://bugs.llvm.org/show_bug.cgi?id=33575 for making the warning in clang useful and for turning it on again.
,
Jun 23 2017
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by r...@chromium.org
, Jun 17 2016I think a better check would be to remember which enums have the wrong sign in MSVC mode, and then if we see an ordering comparison on a value of that enum, we can warn: // Underlying type is 'unsigned' on Linux and 'int' on Windows enum E { E0 = 1, E1 = 0xffffffff, }; void f(int v) { if (v < E1) { // warn ... } Such a warning would probably have to look through implicit integer promotions. Anyway, we can turn it off by default and move it out of -Wmicrosoft for now.