The previous implemetation was just plain broken for most of
possible uses, the new one should work (even though it is ugly
as all hell, and should be improved ASAP).
Fixes#1436
This adds support for templated tests and test methods via
`TEMPLATE_TEST_CASE` and `TEMPLATE_TEST_CASE_METHOD` macros. These
work mostly just like their regular counterparts*, but take an
unlimited** number of types as their last arguments.
* Unlike the plain `TEST_CASE*` macros, the `TEMPLATE*` variants
require a tag string.
** In practice there is limit of about 300 types.
No matcher actually uses it, and there is no good reason for it,
as the best it can do for user is removing a single indirection
when using the pointer inside the matcher. Given the overhead of
other code that will be running during such time, it is completely
meaningless.
This also fixes compilation for PredicateMatcher<const char*>.
By default, it expands into a `static_assert` + `SUCCEED` pair, but
it can also be deferred to runtime by defining
`CATCH_CONFIG_RUNTIME_STATIC_REQUIRE`, which causes it to expand
into plain old `REQUIRE`.
Closes#1362Closes#1356
Previously a mismatched prefix would be skipped before the actual
comparison would be performed. Obviously, it is supposed to be
_matching_ prefix that is skipped.
The StringMaker is off by default and can be enabled by a new macro `CATCH_CONFIG_ENABLE_VARIANT_STRINGMAKER`, to avoid increasing the footprint of stringification machinery by default.
The support is to be considered experimental, that is, the interfaces,
the first party generators and helper functions can change or be removed
at any point in time.
Related to #850
Happening when using clang and templated operators, clang cannot decide
between the operator provided by ReusableStringStream and the one provided
by the value value as both are templates. This is easily solved by calling
the operator<< through the member syntax.
Fixes#1285
This support is based on overriden `std::exception::what` method, so
if an exception does not do so meaningfully, the message is still
pointless.
This is only used as a fallback, both `StringMaker` specialization and
`operator<<` overload have priority..
The fix leaves an open question: should we keep treating refs
to static array of chars as strings, or should we instead
use `strnlen` to check if it is null-terminated within the buffer
Fixes#1238
DJGPP cross compiler is targeting DOS which does not support POSIX
signals. Probably for the same reason (targeting DOS) this compiler
does not support wide characters.
