-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add STATIC_CHECK and STATIC_CHECK_FALSE #2318
Conversation
I tried to approve the new tests as explained in the documentation, but some of the new files contain absolute file paths, which I believe is a problem. It only seems to affect the xml and sonarqube files. |
What do the paths look like? The Approvals should already do some path normalization to avoid this. |
And
I ran |
So the problem is that the scripts taking care of normalization don't check for the right path. I vaguely remember having this problem before (in fact I think the Can you try adding |
docs/other-macros.md
Outdated
@@ -59,7 +59,7 @@ TEST_CASE( "SUCCEED showcase" ) { | |||
} | |||
``` | |||
|
|||
* `STATIC_REQUIRE` | |||
* `STATIC_REQUIRE` and `STATIC_CHECK` | |||
|
|||
> [Introduced](https://github.com/catchorg/Catch2/issues/1362) in Catch2 2.4.2. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should probably be edited to be along the lines of "STATIC_REQUIRE
was introduced ..." and then having a "STATIC_CHECK
was introduced in ..." separately.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
|
This prints I also tried to run it with WSL2 just in case, where I get |
Done, though I didn't notice a difference in the test output. Are the extra tests run by |
So the Python uses windows-standard path separators, while the compiler uses forward slashes. 🤦 |
Can you try cherry-picking 83d9a63 to see if it fixes the problem? |
Yeah, it's much better with that, it solves the issue 😄 How do we proceed next? Do you want to commit on |
Yeah, it is merged to Also don't worry about the CI failure, that one is caused by AppVeyor having some workers stuck with bad image. |
Ok then. Are there still things to address, or can I proceed with the rebase squash? |
MORE TESTS!!!! 😈 Bit more seriously, I realized that at least one easy-to-write test is missing. Please add tests for both It would also be nice to have a test for the motivating behaviour, which is that runtime-deferred |
No bully 😢
I added really simple ones to the existing
I'm willing to add those if needed, but I'm not sure where to put them. Maybe in |
Codecov Report
@@ Coverage Diff @@
## devel #2318 +/- ##
=======================================
Coverage 90.97% 90.97%
=======================================
Files 151 151
Lines 7235 7235
=======================================
Hits 6582 6582
Misses 653 653 |
Yeah, those are fine.
They would require a bunch of work, because they have to be integration-level checks (there needs to be check that 2 assertions failed in the test case that contains the |
Oh damn, integration tests? I guess that I will remain on the sidelines and just watch what you're doing just in case I ever need to do something similar in the future 😅 |
Description
This PR adds two new macros to Catch2:
STATIC_CHECK
andSTATIC_CHECK_FALSE
. As mentioned on Discord, my reason to propose those is to allow the following development workflow:static_assert
s so that failures happen soon at compile time, so that I can be noticed early without having to compile and run the rest of the tests.CATCH_CONFIG_RUNTIME_STATIC_REQUIRE
, transforming those failure into runtime ones that can be aggregated in the reporter.Questions
There are two potential design issues with this PR:
STATIC_CHECK
but effectively acts as aREQUIRE
when it fails at compile time. It might be a bit confusing, but it is the behaviour I want so unless we invent a new name there isn't much we can do about it.CATCH_CONFIG_RUNTIME_STATIC_REQUIRE
. I think that it makes sense to have a single macro for both, but this macro name specifically mentionsSTATIC_REQUIRE
, which is mildly confusing. Catch2 v3 isn't out, so it's theoretically still time to change the macro name if you feel like it. I personally don't mind.