summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite/test
diff options
context:
space:
mode:
authorReid Kleckner <rnk@google.com>2019-09-11 01:01:06 +0000
committerReid Kleckner <rnk@google.com>2019-09-11 01:01:06 +0000
commit7b4237d3ccb6bb84d2d6d411b6bd654f1c932b52 (patch)
tree0be09201c637ac57d7e3c8f26803ea98267c4fbc /lldb/packages/Python/lldbsuite/test
parent068b3628149884ba3cbf98a843ac7b7297423d21 (diff)
downloadbcm5719-llvm-7b4237d3ccb6bb84d2d6d411b6bd654f1c932b52.tar.gz
bcm5719-llvm-7b4237d3ccb6bb84d2d6d411b6bd654f1c932b52.zip
Emit -Wmicrosoft-enum-value warning instead of error in MS ABI
Summary: The first NFC change is to replace a getCXXABI().isMicrosoft() check with getTriple().isWindowsMSVCEnvironment(). This code takes effect in non-C++ compilations, so it doesn't make sense to check the C++ ABI. In the MS ABI, enums are always considered to be "complete" because the underlying type of an unfixed enum will always be 'int'. This behavior was moved from -fms-compatibility to MS ABI back in r249656. The second change is functional, and it downgrades an error to a warning when the MS ABI is used rather than only under -fms-compatibility. The reasoning is that it's unreasonable for the following code to reject the following code for all MS ABI targets with -fno-ms-compatibility: enum Foo { Foo_Val = 0xDEADBEEF }; This is valid code for any other target, but in the MS ABI, Foo_Val just happens to be negative. With this change, clang emits a -Wmicrosoft-enum-value warning on this code, but compiles it without error. Fixes PR38478 Reviewers: hans, rsmith, STL_MSFT Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67304 llvm-svn: 371581
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud