steakhal wrote: For the record, I got bitten by this today and wasted about 5 minutes of my time. I had a pretty good instinct that `Call.getReturnValue()` must refer to the `State` bundled with `Call`, and not the one I just prepared with `bindExpr` binding the return value. (I was inside an evalCall, where all of these are common operations) So this should underline your suggestion. We should separate out `State` from `CallEvent` or have some layer that would ensure that the State attached with a Call is always up to date.
> > 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. https://github.com/llvm/llvm-project/pull/160707 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
