================
@@ -388,8 +389,8 @@ void ExprEngine::processCallExit(ExplodedNode *CEBNode) {
// Step 5: Perform the post-condition check of the CallExpr and enqueue the
// result onto the work list.
// CEENode -> Dst -> WorkList
- NodeBuilderContext Ctx(Engine, calleeCtx->getCallSiteBlock(), CEENode);
- SaveAndRestore<const NodeBuilderContext *> NBCSave(currBldrCtx, &Ctx);
+ setCurrLocationContextAndBlock(CEENode->getLocationContext(),
+ calleeCtx->getCallSiteBlock());
----------------
NagyDonat wrote:
I thought a bit about this, and I think that in this `processCallExit` callback
it makes sense to run the two halves of the logic in different contexts, to
ensure that the first half provides "the same sort of context" that is used
with other uses `removeDead` and the second half provides "the same sort of
context" that is used for other `PostStmt` callbacks. (This is not a deep
analysis, I'm just 85% sure about this.)
If I really wanted to fit this `CallExit` procedure into the "single context
through the whole `dispatchWorkItem`" paradigm, I would've split this long
process into two separate work items (at the point of the context change).
However, I don't think that this would provide practical benefits, so I don't
intend to pursue this direction.
https://github.com/llvm/llvm-project/pull/186182
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
