aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Support/DynamicLibrary.cpp
diff options
context:
space:
mode:
authorNico Weber <nicolasweber@gmx.de>2017-04-21 20:12:26 +0000
committerNico Weber <nicolasweber@gmx.de>2017-04-21 20:12:26 +0000
commit7beed8544ad52fe55e7abb3b0279a286625f0611 (patch)
tree71c2365489a5d034cfd6ec0707ad1ff4638eb031 /llvm/lib/Support/DynamicLibrary.cpp
parentdbd1c5cda36b17c77b77bc0d845f0c726ea78181 (diff)
downloadllvm-7beed8544ad52fe55e7abb3b0279a286625f0611.zip
llvm-7beed8544ad52fe55e7abb3b0279a286625f0611.tar.gz
llvm-7beed8544ad52fe55e7abb3b0279a286625f0611.tar.bz2
[ms] Give -Wmicrosoft-enum-forward-reference a chance to fire in clang-cl, PR32736
clang-cl sets MicrosoftCompat. In that mode, we always give enums a fixed underlying type, and for enums with fixed underlying type we never enter the block that tries to emit ext_ms_forward_ref_enum. Fix this by requiring an explicit underlying type when we're skipping this diagnostic. We had a test for this warning, but it only ran in C++98 mode. clang-cl always enables -std=c++14, so MicrosoftCompatibiliy-cxx98.cpp is a fairly useless test. Fold it into MicrosoftCompatibility.cpp -- that way, the test checks if -Wmicrosoft-enum-forward-reference can fire in clang-cl builds. https://reviews.llvm.org/D32369 llvm-svn: 301032
Diffstat (limited to 'llvm/lib/Support/DynamicLibrary.cpp')
0 files changed, 0 insertions, 0 deletions