JonasToth added a comment. > 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.
Agree. I think this check is good to go. I would commit this check tomorrow if that is ok with you. 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
