Catch passes an RNG which accepts int to random_shuffle. Inside
random_shuffle, the STL tries to call that RNG with the difference_type
of the user provided iterators. For std::vector, this is ptrdiff_t,
which on amd64 builds is wider than int. This triggers a narrowing
warning because the 64 bit difference is being truncated to 32 bits.
Note that this RNG implementation still does not produce a correctly
uniformly shuffled result -- it's currently asserting that std::rand
can produce 1000000 which is false -- but I don't know enough about
how much repeatable shuffles are necessary here, so I'm leaving that
alone for now.
This commit fixes the following scenario:
* You have a test that compares strings with embedded control
characters.
* The test fails.
* You are using JUnit tests within TeamCity.
Before this commit, the JUnit report watcher fails on parsing the XML
for two reasons: the control characters are missing a semicolon at the
end, and the XML document doesn't specify that it is XML 1.1.
XML 1.0 --- what we get if we don't specify an XML version --- doesn't support embedding control characters --- see
http://stackoverflow.com/questions/404107/why-are-control-characters-illegal-in-xml
for all of the gory details.
This is based on PR #588 by @mrpi
Instead of `exit(1)`, it now throws `std::runtime_error` with the details
of the failure. This exception is handled in `run()` at a higher level where
the log is printed to cerr and the test gracefully exits.
- it was forward declared as a class, which caused warnings on some compilers. It should really have been a class anyway.
- this addresses the same issue as PR #534, albeit from the other angle.
I've incremented the minor release number. This is a slight abuse of semantic versioning so let me explain:
I've slightly changed how matchers are used. The matcher macro (REQUIRE_THAT/ CHECK_THAT) used to introduce the Catch::Matchers namespace before the macro token for the matcher, to save you having import the namespace yourself.
The trouble is if the matcher token is not a simple matcher (can now be an expression) this breaks!
So I've removed that qualification. Now if you use Matchers you'll have to do somethings like using namespace Catch::Matchers to bring them in.
This is a breaking change - but, OTTOH, Matchers are an undocumented "beta' feature that I've stated in the past is not guaranteed to have a stable API - so I don't think this warrants a major version change - but I did want to make it significant enough that people do notice that something is going on - and perhaps lead them to this commit message.
