22750cde0e
Clang-tidy is smart enough to understand that the conditional is never updated in the loop body. It will let you get away with it if it can prove that the conditional is always false, but that is not always possible. Here is an example where it's not able to prove it, and thus gives a false positive. This is a minimal reproduction of an actual case I hit in production, where `function` is picking the function based on some `constexpr` logic related to which type argument is currently being tested. ``` int f(); TEMPLATE_TEST_CASE("reproduction", "", int) { const auto function = []() { return f; }(); const int error = function(); REQUIRE(error == 0); // clang-tidy complains: bugprone-infinite-loop } ``` I did not choose to add this test to the test suite, since we're not running `clang-tidy` in CI afaik. To run it manually, simply add the snippet above somewhere and run clang-tidy with `--checks=bugprone-infinite-loop`. Or see an example at https://godbolt.org/z/4v8b8WexP. The reason we get the infinite loop warning in the first place is the conditional at the end of this `do`-loop. Ideally, this conditional would just be `while(false)`, but the actual content of the `REQUIRE`-statement has been included here too in order to not loose warnings from signed/unsigned comparisons. In short, if you do `REQUIRE(i < j)`, where `i` is a negative signed integer and `j` is an unsigned integer, you're supposed to get a warning from `-Wsign-compare`. Due to the decomposition in Catch2, you lose this warning, which is why the content of the `REQUIRE` statement has been added to the conditional to force the compiler to evaluate the actual comparison as well. This was discussed on Discord today, and an alternative approach (which I don't have time to implement) would be to in the decomposition replace the comparison operators with `cmp_less` and friends. These are C++20 though, and would have to be implemented manually. I am also not sure it's a good idea to "magically" change the semantics of `<` when it's used inside a `REQUIRE` macro. Another alternative approach would be to trigger this warning in a different way, by including the content of the `REQUIRE` macro in a different way which doesn't affect the for loop. But I don't have enough of an overview here to know where would be a good place and how to test that I didn't break anything. |
||
---|---|---|
.conan | ||
.github | ||
CMake | ||
data/artwork | ||
docs | ||
examples | ||
extras | ||
fuzzing | ||
src | ||
tests | ||
third_party | ||
tools | ||
.clang-format | ||
.gitattributes | ||
.gitignore | ||
appveyor.yml | ||
BUILD.bazel | ||
CMakeLists.txt | ||
CODE_OF_CONDUCT.md | ||
codecov.yml | ||
conanfile.py | ||
Doxyfile | ||
LICENSE.txt | ||
mdsnippets.json | ||
README.md | ||
WORKSPACE |
Catch2 v3 is being developed!
You are on the devel
branch, where the next major version, v3, of
Catch2 is being developed. As it is a significant rework, you will
find that parts of this documentation are likely still stuck on v2.
For stable (and documentation-matching) version of Catch2, go to the
v2.x
branch.
For migrating from the v2 releases to v3, you should look at our documentation. It provides a simple guidelines on getting started, and collects most common migration problems.
What's the Catch2?
Catch2 is mainly a unit testing framework for C++, but it also provides basic micro-benchmarking features, and simple BDD macros.
Catch2's main advantage is that using it is both simple and natural. Tests autoregister themselves and do not have to be named with valid identifiers, assertions look like normal C++ code, and sections provide a nice way to share set-up and tear-down code in tests.
How to use it
This documentation comprises these three parts:
- Why do we need yet another C++ Test Framework?
- Tutorial - getting started
- Reference section - all the details
More
- Issues and bugs can be raised on the Issue tracker on GitHub
- For discussion or questions please use the dedicated Google Groups forum or our Discord
- See who else is using Catch2