haoNoQ wrote: > > > If this is NFC, let's adjust the PR title. If has behavioral change, > > > let's have a test exposing that and split off the refactor parts. > > > > I will create a test with a new debug checker which modifies the state in > > its `PreCall` callback and validates that the modification is visible > > through the `CallEvent` objects received by the `EvalCall` and > > `PointerEscape` callbacks. Is this sufficient, or would you prefer a > > different kind of test? > > I think the best way to go about this is a unittest with a custom bug report > visitor that prints a special trait along the path. Like a logger. And the > visitor would print these values alongside the ProgramPoint it is attached to.
I think the assertion I propose is the easiest way to test this patch. I.e., the fact that the newly added assertion used to crash without the rest of the patch but doesn't crash anymore, is a sufficient defense against regressions in and of itself. And that's very TDD: you first add a new contract to the system, then you change the system to fulfill the contract. Like, even if currently the patch doesn't change the observed behavior. But if it does, that'd also be an easy way to identify some real-world code that misbehaves this way, and then you can easily `creduce` it into a LIT test if we don't have one already. (But this could get tedious if more sources of broken states are identified this way and you're not in a position to fix them all at once.) https://github.com/llvm/llvm-project/pull/160707 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
