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*>.
This fixes 3 problems:
* Relative paths on Windows are now supported
* Out-of-tree (paths starting with ../) builds are now supported
* Path separator normalization no longer affects non-path components of input (problem with Compact reporter)
Fixes#1379Fixes#1222Fixes#1200Fixes#1194
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 desired behaviour was to match a literal "[.]", so the regex
has to be escaped as "\\[\\.\\]" -- double backslashes, because
it has to be escaped from CMake as well as from the regex engine.
This means
* Adding new configuration toggle `CATCH_CONFIG_DISABLE_EXCEPTIONS`
and a best-guess configuration auto-checking for it.
* Adding new set of internal macros, `CATCH_TRY`, `CATCH_CATCH_ALL`
and `CATCH_CATCH_ANON` that can be used in place of regular `try`,
`catch(...)` and `catch(T const&)` respectively, while disappearing
when `CATCH_CONFIG_DISABLE_EXCEPTIONS` is enabled.
* Replacing all uses of `throw` with calls to `Catch::throw_exception`
customization point.
* Providing a default implementation for the above customization point
when `CATCH_CONFIG_DISABLE_EXCEPTIONS` is set.
* Letting users override this implementation with their own.
* Some minor changes and ifdefs all around to support the above
Because of a change in VS toolset, missing option <UseFullPaths>
is no longer interpreted as "don't pass /FC to the compiler", but
rather as "pass /FC to the compiler". This is problematic, because
/FC not only changes how much of the path is reporter by the compiler
(e.g. in `__FILE__` macro), but it also lower cases the path.
This lower-casing of the path broke our approval tests for VS2017
about 5 months ago.
Using CMake 3.13 (not yet released) would also let us fix it, but
for now we use a vcxproj.user file that is merged with the main project
and explicitly disables `/FC`.
This means
* a new cmake option, `CATCH_BUILD_EXTRA_TESTS`, that conditionally
includes the ExtraTests subfolder
* building and running them on some of the Travis build images
* An example configuration test
In the future these should be extended to cover most of the
configuration options in Catch2, but this is a start.
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
This also goes for pkg-config installed by our CMake installation.
This includes
* Updating CMake version on Travis
* Adding a `Catch2` subfolder to the `single_include/` folder to
provide this include path both _inside_ the repository, and _outside_.
* Updated examples to build with the new paths
* Other general CMake cleanup
- seems the #ifdef was necessary after all, because of the difference in the way the cpp files are included in the full project vs the single include
- in the OC project I moved the #include of catch_tostring.cpp first. That solves the project for now, but is a brittle solution
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
There are still some holes, e.g. we leave surrogate pairs be
even though they are not a part of valid UTF-8, but this might
be for the better -- WTF-8 does support surrogate pairs inside
text.
Closes#1207
