catch3/src/catch2/internal/catch_compiler_capabilities.hpp, branch v3.15.3 Progmasoft Catch3: an independently maintained C++17 test framework with a parallel runner, property checks, snapshots and structured results. Support for constexpr matchers in C++20 (P0784) 2026-05-12T09:05:02+00:00 Martin Hořeňovský 2026-05-10T21:05:46+00:00 651247c7f40eda6846fec736d2f9edac8949dacb To make this all work, I had to remove the stringification cache from matchers. In theory, this can cause performance penalty in cases where single matcher instance is stringified multiple times, but in practice this does not happen much, and the difference is surprisingly small anyway, because the performance of stringification is already horrible and full of allocating strings just to throw them away. The matcher combinators need P2738 from C++26 to be `constexpr`. Closes #3091 
To make this all work, I had to remove the stringification cache
from matchers. In theory, this can cause performance penalty in
cases where single matcher instance is stringified multiple times,
but in practice this does not happen much, and the difference is
surprisingly small anyway, because the performance of stringification
is already horrible and full of allocating strings just to throw
them away.

The matcher combinators need P2738 from C++26 to be `constexpr`.

Closes #3091
Don't check if __cplusplus is defined 2026-05-10T18:48:58+00:00 Martin Hořeňovský 2026-05-10T18:48:45+00:00 15b9393f0f32327e28833c5032b2c4e02c31d82c 






Suppress __COUNTER__ warning from newest Clang versions
2026-04-01T08:34:58+00:00

Martin Hořeňovský

2026-04-01T08:34:54+00:00

51b0532d1fba061d0802ccfd906cc87fc2dd49c2

Ideally we could suppress the warning locally in the `UNIQUE_NAME` macro,
but that runs into at least 2 issues:

1) Clang actually does not consider the warning as coming from inside the
   `UNIQUE_NAME` macro, even though it correctly points to its expansion
   as the problem. This means that adding `_Pragma`s inside the macro
   around the __COUNTER__ usage does not actually silence the warning.

2) Adding the local suppressions anyway breaks the expansion of
   `MAKE_NAMESPACE` macro inside the templated test case macros. This can
   be fixed for the newest clang version by removing its use and using
   the uniqued `TestName` for the namespace name directly, but this breaks
   compilation on GCC, and older Clang versions.

Because of these issues, we introduce global warning suppression for
`-Wc2y-extensions` to be done with it. We should revisit this if Clang 23
fixes the local pragma based suppression, when it might be worth the effort
to rework the templated test case macros to support it.

Closes #3076





Ideally we could suppress the warning locally in the `UNIQUE_NAME` macro,
but that runs into at least 2 issues:

1) Clang actually does not consider the warning as coming from inside the
   `UNIQUE_NAME` macro, even though it correctly points to its expansion
   as the problem. This means that adding `_Pragma`s inside the macro
   around the __COUNTER__ usage does not actually silence the warning.

2) Adding the local suppressions anyway breaks the expansion of
   `MAKE_NAMESPACE` macro inside the templated test case macros. This can
   be fixed for the newest clang version by removing its use and using
   the uniqued `TestName` for the namespace name directly, but this breaks
   compilation on GCC, and older Clang versions.

Because of these issues, we introduce global warning suppression for
`-Wc2y-extensions` to be done with it. We should revisit this if Clang 23
fixes the local pragma based suppression, when it might be worth the effort
to rework the templated test case macros to support it.

Closes #3076







fix: add missing backslash in macro definition
2026-03-30T12:23:17+00:00

Joseph Edwards

2026-03-27T16:33:03+00:00

2ec64d12b198cd25a9ca84230a2be7cfd24494fa












🐛 Clang on Windows will define _MSC_VER and trip up these checks -- make it actually Visual C++-specific
2026-01-19T14:14:53+00:00

ThePhD

2026-01-16T04:36:05+00:00

de7e8630134f46e67a6b59269436f9cab94cd28e












Suppress static analysis warning 26426 for Windows/MSVC builds (#3057)
2026-01-01T21:56:14+00:00

OliverBeeckAVM

2026-01-01T21:56:14+00:00

b7e31c9ab3a4b6f7ef5f11d01aa3453c03e695b6

Suppress `Global initializer calls a non-constexpr function 'Catch::makeTestInvoker' (i.22).`,
which is issued when using macro `TEST_CASE` for windows/MSVC builds.


---------

Co-authored-by: Martin Hořeňovský <martin.horenovsky@gmail.com>




Suppress `Global initializer calls a non-constexpr function 'Catch::makeTestInvoker' (i.22).`,
which is issued when using macro `TEST_CASE` for windows/MSVC builds.


---------

Co-authored-by: Martin Hořeňovský <martin.horenovsky@gmail.com>






Fix non-desktop Windows platforms not defining CATCH_INTERNAL_CONFIG_NO_COLOUR_WIN32 correctly

2025-09-17T18:25:26+00:00

Silent

2025-09-17T11:23:24+00:00

dc3a4ea41a78c643fbfa07b1cb456738c9e25ef6


Fixes building on non-desktop GDK platforms.





Fixes building on non-desktop GDK platforms.






Fix: Clang 19 -Wc++20-extensions warning (#2910)
2025-04-07T21:45:34+00:00

abhishekbelgaonkar23

2024-11-16T08:11:56+00:00

f51dc98dfcaecf402e2d3aa3e0282b27beb4e237












Allow disabling use of __builtin_constant_p in internal macros
2024-10-27T19:27:03+00:00

Martin Hořeňovský

2024-10-27T16:08:47+00:00

e26028880790addff43cc5546de1e39214d86a04

Turns out that even in GCC, the expression in `__builtin_cosntant_p`
can end up evaluated and side-effects executed. To allow users to
work around this bug, I added a configuration option to disable its
use in internal macros.

Related to #2925





Turns out that even in GCC, the expression in `__builtin_cosntant_p`
can end up evaluated and side-effects executed. To allow users to
work around this bug, I added a configuration option to disable its
use in internal macros.

Related to #2925







Remove obsolete C++14 define
2024-02-12T23:01:19+00:00

Martin Hořeňovský

2024-02-12T23:01:13+00:00

4570fca24b2fd04f82f2376b090abfa5dde965c3

There is no reason to have code conditional on C++14, because C++14
is the minimum supported language standard for v3.





There is no reason to have code conditional on C++14, because C++14
is the minimum supported language standard for v3.