aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/ProfileData/Coverage/CoverageMapping.cpp
diff options
context:
space:
mode:
authorRoman Lebedev <lebedev.ri@gmail.com>2017-10-24 21:05:43 +0000
committerRoman Lebedev <lebedev.ri@gmail.com>2017-10-24 21:05:43 +0000
commit7ade0173df8fe6aaab5b5fe2fe39fb1fdc7dffc7 (patch)
tree4a260f2653984493cf4935b0dc5db8f93b212e49 /llvm/lib/ProfileData/Coverage/CoverageMapping.cpp
parentac7aaeb770fb43df64b2b3598aa27541666393ed (diff)
downloadllvm-7ade0173df8fe6aaab5b5fe2fe39fb1fdc7dffc7.zip
llvm-7ade0173df8fe6aaab5b5fe2fe39fb1fdc7dffc7.tar.gz
llvm-7ade0173df8fe6aaab5b5fe2fe39fb1fdc7dffc7.tar.bz2
[Sema] Document+test the -Wsign-compare change for enums in C code [NFC]
rL316268 / D39122 has fixed PR35009, and now when in C, these three(?) diagnostics properly use the enum's underlying datatype. While it was fixed, the test coverage was clearly insufficient, because the -Wsign-compare change didn't show up in any of the tests, until it was reported in the post-commit mail for rL316268. So add the test for the -Wsign-compare diagnostic for enum for C code, and while there, document this in the release notes. The fix itself was obviously correct, so unless we want to silence this new diagnosed case, i deem this commit to be NFC. llvm-svn: 316500
Diffstat (limited to 'llvm/lib/ProfileData/Coverage/CoverageMapping.cpp')
0 files changed, 0 insertions, 0 deletions