The two changes are
`catch_matchers_templates` -> `catch_matchers_templated` and
`catch_matchers_generic` -> `catch_matchers_predicate`. The former
is mostly cosmetic, but the second was previously significantly
misleading, and as the library is now to be consumed by including
specific headers, this needed to be fixed.
`SizeIs` can accept both `size_t` and a matcher. In the first case,
it checks whether the size of the range is equal to specified size.
In the second case, it checks whether the provided matcher accepts
the size of the range.
In general, for Catch2 v3 we are making virtual types `final`,
unless they were explicitly designed to be derived-from.
`ListeningReporter` is definitely not designed to be derived-from.
This commit also forbids composing lvalues of composed matchers, as
per previous deprecation notice. I do not expect this to be contentious
in practice, because there was a bug in that usage for years, and
nobody complained.
Given that in the 2 or so years that matchers are thing nobody complained,
it seems that people do not actually write this sort of code, and the
possibility will be removed in v3. However, to avoid correctness bugs,
we will have to support this weird code in v2.
Now that Catch2 is a proper library, we can always build the full
library (comparatively minor slowdown) and the user can avoid
including benchmarking headers to avoid the compilation slowdown.
Now that the recommended distribution and usage method is proper
library, users can just avoid including the matcher headers to get
basically the same effect.
Users can still write a description for their sections, but it will
no longer be saved as part of the `SectionInfo` struct. This ability
has also been added to the documentation.
Closes#1319
This also required some refactoring of how the pattern matching
works. This means that the concepts of include and exclude patterns
are no longer unified, with exclusion patterns working as just
negation of an inclusion patterns (which led to including hidden
tags by default, as they did not match the exclusion), but rather
both include and exclude patterns are handled separately.
The new logic is that given a filter and a test case, the test
case must match _all_ include patterns and _no_ exclude patterns
to be included by the filter. Furthermore, if the test case is
hidden, then the filter must have at least one include pattern
for the test case to be used.
Closes#1184
Previously it returned the sum of listed things because ???. This
was completely useless and in many ways actively counterproductive
because of the success/failure conventions around exit codes.
Closes#1410
Unless someone steps up to fix the long link times with a set of
unobtrusive changes, the recommended solution will remain "use a better
linker".
Related to #1205, #1247, and #1637Closes#1247Closes#1637
Only works for exceptions that publicly derive from `std::exception`
and the matching is done exactly, including case and whitespace.
Closes#1649Closes#1728
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Your branch is up-to-date with 'origin/master'.
#
# Changes to be committed:
# modified: ../docs/matchers.md
# modified: ../include/internal/catch_capture_matchers.h
# modified: ../projects/CMakeLists.txt
# modified: ../projects/SelfTest/Baselines/compact.sw.approved.txt
# modified: ../projects/SelfTest/Baselines/console.std.approved.txt
# modified: ../projects/SelfTest/Baselines/console.sw.approved.txt
# modified: ../projects/SelfTest/Baselines/junit.sw.approved.txt
# modified: ../projects/SelfTest/Baselines/xml.sw.approved.txt
# modified: ../projects/SelfTest/UsageTests/Matchers.tests.cpp
#
# Untracked files:
# ./
# ../clang-full/
# ../clang-test/
# ../clang10-build/
# ../coverage-build/
# ../gcc-build/
# ../gcc-full/
# ../include/internal/catch_matchers_exception.cpp
# ../include/internal/catch_matchers_exception.hpp
# ../misc-build/
# ../msvc-sln/
# ../notes.txt
# ../test-install/
#
* Units from <ratio> are no longer redeclared in our own namespace
* The default clock is `steady_clock`, not `high_resolution_clock`,
because, as HH says "high_resolution_clock is useless. If you want
measure the passing of time, use steady_clock. If you want user
friendly time, use system_clock".
* Benchmarking support is opt-in, not opt-out, to avoid the large
(~10%) compile time penalty.
* Benchmarking-related options in CLI are always present, to decrease
the amount of code that is only compiled conditionally and making
the whole shebang more maintainble.
