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. Repository: rCTE Clang Tools Extra https://reviews.llvm.org/D53974 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
