catch3/include/internal, branch v2.12.2 Progmasoft Catch3: an independently maintained C++17 test framework with a parallel runner, property checks, snapshots and structured results. v2.12.2 2020-05-25T13:13:18+00:00 Martin Hořeňovský 2020-05-25T13:13:18+00:00 b1b5cb812277f367387844aab46eb2d3b15d03cd 






Really fix use of std::result_of when invoke_result is available
2020-05-22T08:05:34+00:00

Martin Hořeňovský

2020-05-21T19:39:19+00:00

77dc8cfc45e7bae1d1219bac2e06bac87eb8c6b1

Closes #1934





Closes #1934







Avoid using std::result_of when std::invoke_result is available
2020-05-21T19:39:19+00:00

Martin Hořeňovský

2020-05-21T19:39:19+00:00

ddc9f4c61df438952a4c0c2e451d25677ecf4b2b

Closes #1934





Closes #1934







Remove obsolete comment in UnorderedEquals vector matcher
2020-05-18T12:29:50+00:00

Martin Hořeňovský

2020-05-18T12:29:50+00:00

bed47374cee07c6f9fec1a84d1afddba887fe731












Fix compilation failure when using libstdc++10 (#1929)
2020-05-15T09:30:12+00:00

Natsu

2020-05-15T09:30:12+00:00

c190061001739e8bf240a78059f1a3e927a35efc

The issue is caused by deleted `std::__detail::begin` declared in `bits/iterator_concepts.h`. This would be found by ADL, and because it is deleted, compilation would fail. This change makes it so that we SFINAE on `begin(std::declval<T>())` and `end(std::declval<T>())` being well-formed.





The issue is caused by deleted `std::__detail::begin` declared in `bits/iterator_concepts.h`. This would be found by ADL, and because it is deleted, compilation would fail. This change makes it so that we SFINAE on `begin(std::declval<T>())` and `end(std::declval<T>())` being well-formed.







Fix invalid isspace call detected by PREfast
2020-05-12T12:07:22+00:00

Billy Robert O'Neal III

2020-05-12T03:38:09+00:00

b1dcdc5032f09cab0a5834476d85e999bb608ce6

D:\vcpkg\toolsrc\include\catch2\catch.hpp(11285): warning C6330: 'char' passed as _Param_(1) when 'unsigned char' is required in call to 'isspace'.
D:\vcpkg\toolsrc\include\catch2\catch.hpp(11288): warning C6330: 'char' passed as _Param_(1) when 'unsigned char' is required in call to 'isspace'.

ISO/IEC 9899:2011:
"7.4 Character handling <ctype.h>"/1
[...] In all cases the argument is an int, the value of which shall be
representable as an unsigned char or shall equal the value of the macro
EOF. If the argument has any other value, the behavior is undefined.

This means if isspace was passed a character like ñ it could corrupt
memory without the static_cast to treat it as a positive value after
integral promotion (and C libraries commonly use the int index supplied
as a key into a table which result in out of bounds access if the
resulting int is negative).





D:\vcpkg\toolsrc\include\catch2\catch.hpp(11285): warning C6330: 'char' passed as _Param_(1) when 'unsigned char' is required in call to 'isspace'.
D:\vcpkg\toolsrc\include\catch2\catch.hpp(11288): warning C6330: 'char' passed as _Param_(1) when 'unsigned char' is required in call to 'isspace'.

ISO/IEC 9899:2011:
"7.4 Character handling <ctype.h>"/1
[...] In all cases the argument is an int, the value of which shall be
representable as an unsigned char or shall equal the value of the macro
EOF. If the argument has any other value, the behavior is undefined.

This means if isspace was passed a character like ñ it could corrupt
memory without the static_cast to treat it as a positive value after
integral promotion (and C libraries commonly use the int index supplied
as a key into a table which result in out of bounds access if the
resulting int is negative).







Silence clang-tidy's hicpp-vararg (alias of coreguidelines vararg)
2020-05-09T16:23:12+00:00

Martin Hořeňovský

2020-05-09T16:23:09+00:00

f0e596e2522f64451f6444edab5c59b8b9e8e082

Ideally, clang-tidy would be smart that if one alias of a warning
is suppressed, then the other one is suppressed as well, but as of
right now, it isn't. This means that for now we have to suppress
both aliases of this warning. Opened upstream issue to fix this:
https://bugs.llvm.org/show_bug.cgi?id=45859

Obviously, ideally clang-tidy would also not warn that we are calling
a vararg function when it is an unevaluated magic builtin, but that
also is not happening right now and I opened an issue for it:
https://bugs.llvm.org/show_bug.cgi?id=45860

Closes #1921





Ideally, clang-tidy would be smart that if one alias of a warning
is suppressed, then the other one is suppressed as well, but as of
right now, it isn't. This means that for now we have to suppress
both aliases of this warning. Opened upstream issue to fix this:
https://bugs.llvm.org/show_bug.cgi?id=45859

Obviously, ideally clang-tidy would also not warn that we are calling
a vararg function when it is an unevaluated magic builtin, but that
also is not happening right now and I opened an issue for it:
https://bugs.llvm.org/show_bug.cgi?id=45860

Closes #1921







v2.12.1
2020-04-21T17:30:38+00:00

Martin Hořeňovský

2020-04-21T17:30:38+00:00

2e61d38c7c3078e600c331257b5bebfb81aaa685

--- Fixes ---
* Vector matchers now support initializer list literals better

--- Improvements ---
* Added support for `^` (bitwise xor) to `CHECK` and `REQUIRE`





--- Fixes ---
* Vector matchers now support initializer list literals better

--- Improvements ---
* Added support for `^` (bitwise xor) to `CHECK` and `REQUIRE`







Add support for bitwise xor to the decomposer
2020-04-21T17:27:12+00:00

Martin Hořeňovský

2020-04-21T17:27:12+00:00

5c9f09e94a32ab47f16bf8353a708e226fccf645












Fixup template type argument inference for vector matchers
2020-04-21T17:09:45+00:00

Martin Hořeňovský

2020-04-21T17:09:45+00:00

f4fc2dab2c5bb8cab11b0a0dde8a8421076c30f9