This should decrease the number of allocations before main is entered
significantly, but complicates the code somewhat in return.
Assuming I used `massif` right, doing just `SelfTest --list-tests`
went from 929 allocations at "Remove gcc-4.9 from the travis builds"
(2 commits up), to 614 allocations with this commit.
Now a `TEST_CASE` macro should create a single TestCaseInfo and then
it should never be copied around. This, together with latter changes,
should significantly decrease the number of allocations made before
`main` is even entered.
According to CMake, it does not support templated variables. Strictly
speaking, we added that to the target so that the project defaults
to C++14, but I am planning to use them inside Catch2 anyway.
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
* Use Xenial as the base distribution
* Remove C++11 builds
* Add a lot more C++14 builds
* Add some C++17 builds
* Include newer versions of Clang and GCC
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
This allows us to provide machine-readable listings through the
XMLReporter and it will also allow users to define their own listing
format that does whatever their own tools need.
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
Previously, each warning suppression was self-contained, with its
own pair of `SUPPRESS_X_WARNING` and `UNSUPPRESS_X_WARNING` macros.
This had the obvious advantage of being self-containing, but it
also meant that if we needed to suppress more than one warning
in a single place, then we would manipulate the compiler's warning
state multiple times, even though logically we would only need one
layer.
The new way of suppressing warnings in macros is to push compiler's
warning state with `CATCH_INTERNAL_START_WARNINGS_SUPPRESSION` macro,
then disable whatever macros we need with the
`CATCH_INTERNAL_SUPPRESS_X_WARNINGS` macro, and then return to the
previous state using `CATCH_INTERNAL_STOP_WARNINGS_SUPPRESSION`.
The JUnit report is improved in that:
* The message shows the testing condition, not the result
* The actual message has similar output than the console one
