Fix significant bug with storing composed matchers

Given that in the 2 or so years that matchers are thing nobody complained,
it seems that people do not actually write this sort of code, and the
possibility will be removed in v3. However, to avoid correctness bugs,
we will have to support this weird code in v2.
This commit is contained in:
Martin Hořeňovský
2020-02-01 20:55:42 +01:00
parent d6b2a3793b
commit f8794634c2
12 changed files with 103 additions and 14 deletions

View File

@@ -686,6 +686,10 @@ ok {test-number} - 5 == c for: 5 == 5
ok {test-number} - 6 == uc for: 6 == 6
# Comparisons with int literals don't warn when mixing signed/ unsigned
ok {test-number} - (std::numeric_limits<uint32_t>::max)() > ul for: 4294967295 (0x<hex digits>) > 4
# Composed matchers are distinct
ok {test-number} - testStringForMatching2(), !composed1 for: "some completely different text that contains one common word" not ( contains: "string" or contains: "random" )
# Composed matchers are distinct
ok {test-number} - testStringForMatching2(), composed2 for: "some completely different text that contains one common word" ( contains: "string" or contains: "random" or contains: "different" )
# Contains string matcher
not ok {test-number} - testStringForMatching(), Contains("not there", Catch::CaseSensitive::No) for: "this string contains 'abc' as a substring" contains: "not there" (case insensitive)
# Contains string matcher
@@ -3684,5 +3688,5 @@ ok {test-number} - q3 == 23. for: 23.0 == 23.0
ok {test-number} -
# xmlentitycheck
ok {test-number} -
1..1838
1..1840