diff options
author | Roman Lebedev <lebedev.ri@gmail.com> | 2017-10-24 21:05:43 +0000 |
---|---|---|
committer | Roman Lebedev <lebedev.ri@gmail.com> | 2017-10-24 21:05:43 +0000 |
commit | 7ade0173df8fe6aaab5b5fe2fe39fb1fdc7dffc7 (patch) | |
tree | 4a260f2653984493cf4935b0dc5db8f93b212e49 /llvm/lib/ProfileData/Coverage/CoverageMapping.cpp | |
parent | ac7aaeb770fb43df64b2b3598aa27541666393ed (diff) | |
download | llvm-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