Repository navigation
Conversation
…rently WILL_FAIL counted any failed build as a rejection, so the reject tests held a lock serializing them: concurrent builds in one tree race on its build-system state. A build failing before it compiled still passed. Scenario targets compile through a CMake-script launcher, which prints a marker only when the compiler exits with a non-zero status after reporting an error at a source line, in the GCC and Clang or the MSVC format, and the tests require that marker. An exit status alone cannot tell: GCC reports its front end killed, as by the OOM killer, and Clang its own crash, with the status of a rejection. A line reporting an internal compiler error never counts, since MSVC reports one at a source line. The launcher replaces any global launcher, such as ccache, on scenario targets only. A setup fixture compiles each reject source without a scenario, through the same launcher, before any scenario runs. This regenerates a stale build system once, keeps a source broken outside its guards from passing every scenario, and catches a launcher that breaks the compile line. The launcher script is an object dependency of the reject sources, so editing it recompiles these controls. A self-test of the launcher's verdicts and argument forwarding also gates the scenarios. Generators other than Ninja and Makefiles ignore compiler launchers, and keep WILL_FAIL with the lock. add_reject_tests moves from tests/CMakeLists.txt into cmake/RejectTests.cmake, beside the launcher, cmake/RejectLauncher.cmake: cmake/ holds the build's CMake code, and tests/util/ the C++ test helpers. The launcher's self-test lives in tests/cmake/, mirroring cmake/. Locally, with gcc 16.2 and Ninja, ctest -j 40 runs the 79 scenarios in 3 s against 70 s serially. In a stale tree the fixture regenerates once and every scenario passes on a compiler error, where the concurrent regenerations used to race and pass all 79 without compiling. With gcc 16.2 and clang 22.1, under Ninja and Makefiles: a scenario that compiles fails; a failing regeneration fails all 79 with the fixture bypassed; a typo outside the guards, or a launcher dropping include paths, fails the fixture and skips the scenarios. With colour diagnostics on, every scenario still passes. No marker is printed for GCC's front end killed while it compiles valid code, for internal compiler errors from GCC's crash and assertion paths, for Clang's crash pragmas, including assertion failures in a build with assertions, or for an MSVC 19.44 internal error replayed from a published build log. Only CI exercises the Visual Studio fallback. Assisted-by: Claude:claude-fable-5-1 Assisted-by: Claude:claude-opus-5-5
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
CTest's label summary then shows the time each group takes. Assisted-by: Claude:claude-opus-5-5
🤖 Augment PR SummarySummary: Strengthens reject-test validation and enables concurrent scenario builds.
🤖 Was this summary useful? React with 👍 or 👎 |
![augmentcode[bot]](https://avatars.githubusercontent.com/in/1027498?s=60&v=4){kind=small}
|
Member
Author
|
augment review |
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Reject tests used
WILL_FAIL, so any build failure counted as a pass, including failures before compilation. A lock ran the tests one at a time to prevent concurrent builds in the same tree from interfering with each other.Scenario targets now compile through
cmake/RejectLauncher.cmake. A reject test passes only when the launcher prints a marker confirming that the compiler reported an error at a source line, in GCC/Clang or MSVC format. A broken build fails the test instead, as does a compiler that is killed, crashes or reports an internal error before it reports such an error.Before the scenarios run, a setup fixture compiles each reject source without a scenario through the same launcher, if any. This regenerates a stale build tree once and prevents errors outside the scenario guards from making every scenario pass. Removing the lock lets
ctest -jrun reject tests concurrently. Other targets keep any global launcher, such as ccache. Visual Studio generators ignore compiler launchers, so they retainWILL_FAILand the lock.The test setup is in
cmake/RejectTests.cmake; the launcher's self-test is intests/cmake/.Tests that run a program carry
fn_runorpfn_run, and reject scenariosfn_rejectorpfn_reject, so CTest's label summary shows the time each group takes. Filter on them with an anchored pattern, such asctest -L '^fn_reject$', sincefn_rejectalone also matchespfn_reject.The full suite passes locally under
ctest -j 40with gcc 16.2 and clang 22.1, using Ninja and Makefiles (142 tests, 92 reject scenarios). Additional checks confirm that:This PR's CI is the first run of the Visual Studio fallback and AppleClang.
Assisted-by: Claude:claude-fable-5-1
Assisted-by: Claude:claude-opus-5-5