[PATCH] D53974: [clang-tidy] new check: bugprone-too-small-loop-variable
Tamás Zolnai via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Sun Nov 11 10:42:18 PST 2018
ztamas added a comment.
In https://reviews.llvm.org/D53974#1294659, @JonasToth wrote:
> >> I would be very interested why these false positives are created. Is there a way to avoid them and maybe it makes sense to already add `FIXME` at the possible places the check needs improvements.
> > voidForLoopFalsePositive() and voidForLoopFalsePositive2() test cases covers most of the false positives found in LibreOffice.
> I would not consider them as full false positives, the constants that are created allow to filter more, but type-based the diagnostics are correct. So I think that is fine. If the constants would be a big value, the check does find a real problem.
Yes, that's right, these are not full false positives, but the check's main focus is on those loops which are runtime dependent. If a loop's upper bound can be calculated in compile time then this loop should be caught by a compiler warning based on the actual value of that constant. See -Wtautological-constant-out-of-range-compare for example. So I think it's the best if we can avoid catching these issues using a type based matching.
Anyway, there is not too many of this kind of false positives, so it's not a big issue. In LLVM code I did not find any similar case.
I can't see full false positives where the check works incorrectly. The detected type mismatch seems correctly detected in every case.
rCTE Clang Tools Extra
More information about the cfe-commits