[PATCH] D53974: [clang-tidy] new check: bugprone-too-small-loop-variable

[Jonas Toth via Phabricator via cfe-commits]

JonasToth added a comment.

>> 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.

@whisperity

> I am fairly concerned the example with unsigned use for container iteration are not false positives, just examples of bad happenstance code which never breaks under real life applications due to uint32_t being good enough but is actually not type-safe.
>  Those examples that I kept in my quote are especially bad and should be fixed eventually...

clang-tidy is not about finding _only_ bugs, but find patterns that can be problematic but are not in every instance (therefore `bugprone-` and not `bug-`).
`uint32_t` does not span the whole memory-space for current hardware and a `std::string` can have more then `uint32_t::max` elements. Diagnosing this is valid.
Containers where `uint32_t::max * sizeof(element_type) > size_t::max` could be filtered for normal iteration over the container. I would consider it still a bugprone pattern.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D53974