The compile time improvements from using combined TUs mostly isn't
worth the annoyance they cause with various IDE shortcuts, like
when switching between header and its impl. file.
Splitting them apart also fixes the issue of empty subdirs being
installed due to `foo/internal` folders that only contained the
combined TUs and no headers.
Closes#2457Closes#2463
* GCC5 compat: work around inherited constructor issues
Don't use inherited constructors, forward manually instead. This
basically reverts 61f803126d.
I believe that GCC5 does not implement P0136, a C++17 change that made
inherited constructors actually usable and was backported as a DR all
the way to C++11.
* GCC5 compat: bypass std::pair construction issue
Co-authored-by: Martin Hořeňovský <martin.horenovsky@gmail.com>
Reported as an issue on Discord. I thought that by GCC 9, the
C++ frontend was fixed enough to support `_Pragma`-based
suppression correctly, but apparently I was wrong.
This fixes multiple issues with random generators, with the most
important one being that multiple nested generators could return
values from the same sequence, due to internal implementation
details of `GENERATE`, and how they interact with test case
paths.
The cost of doing this is that given this simple `TEST_CASE`,
```cpp
TEST_CASE("foo") {
auto i = GENERATE(take(10, random(0, 100));
SECTION("A") {
auto j = GENERATE(take(10, random(0, 100));
}
SECTION("B") {
auto k = GENERATE(take(10, random(0, 100));
}
}
```
`k` will have different values between running the test as
a whole, e.g. with `./tests "foo"`, and running only the "B"
section with `./tests "foo" -c "B"`.
I consider this an acceptable cost, because the only alternative
would be very messy to implement, and add a lot of brittle and
complex code for relatively little benefit.
If this calculation changes, we will need to instead walk
the current tracker tree whenever a random generator is being
constructed, check for random generators on the path to root,
and take a seed from them.
This might become potentially useful in the future, when we want
to provide the ability to forward jump generators, to be able to
simply reproduce specific input to a test.
I am not yet sure how it would work, but the basic idea is that
it could be similar to the `-c` switch for selecting specific
`SECTION` in a test case.
The old instruction would cause the debugger to be stuck at the
triggering source line forever, while the new one should have the
expected semantics, where the debugger can then single-step,
continue. or generally do things, afterwards.
Closes#2422
This is kinda messy, because there is no good way to signal to
the compiler that some code uses direct comparison of floating
point numbers intentionally, so instead we have to use diagnostic
pragmas.
We also have to over-suppress the test files, because Clang (and
possibly GCC) still issue warnings from template instantiation
even if the instantion site is under warning suppression, so the
template definition has to be under warning suppression as well.
Closes#2406
The cleanup also found out that custom translation for std-derived
exceptions test wasn't running properly, and fixed that.
We cannot enable the warning globally, because the tests contain
some functions that are unused by design -- e.g. when checking
stringification priority of StringMaker vs range fallback and so
on.
Not all reporters use a format that supports this, so TeamCity
and Automake reporters still do not report it. The console
reporter now reports it even on successful runs, where before
it only reported the rng seed in the header, which was showed
either for failed run, or for run with `-s`.
CLoses#2065
This ended up being a surprisingly large refactoring, motivated
by removing a `const_cast` from `Config`'s handling of reporter
streams, forced by previous commit.
This way it makes much more sense from logically-const point
of view, and also means that concrete implementations don't
have to always have a `mutable` keyword on the stream member.
