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
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.
This allows reducing the amount of friends needed for its interface
and some extra tricks later.
The bad part is that the pointer can become invalidated via
calls to other StringRef's public methods, but c'est la vie.
ReusableStringStream holds a std::ostringstream internally, but only exposes the ostream interface.
It caches a pool of ostringstreams in a vector which is currently global, but will be made thread-local.
Altogether this should enable both runtime and compile-time benefits. although more work is needed to realise the compile time opportunities.
Also hides std::chrono, std::pair and std::chrono::* behind
new configuration macros, CATCH_CONFIG_ENABLE_*_STRINGMAKER
to avoid dragging in <utility>, <tuple> and <chrono> in common
path, unless requested.
Swept:
`-Wpadded` in some places (where it caused extra size, instead of just
saying "hey, we padded struct at the end to align, just as standard says")
`-Wweak-vtables` everywhere (Clang)
`-Wexit-time-destructors` everywhere (Clang)
`-Wmissing-noreturn` everywhere (Clang)
The last three are enabled for Clang compilation going forward.
Also enabled `-Wunreachable-code` for Clang and GCC
A) non-const comparison operators should not exist and should not be
encouraged
B) The logic breaks comparing function pointers certain way
C) It was inconsistent anyway, as it only applied to `==` and `!=`
Closes#925
