================
@@ -3719,20 +3719,20 @@
REGISTER_TRAIT_WITH_PROGRAMSTATE(LastEagerlyAssumeExprIfSuccessful,
void ExprEngine::evalEagerlyAssumeBifurcation(ExplodedNodeSet &Dst,
ExplodedNodeSet &Src,
const Expr *Ex) {
- NodeBuilder Bldr(Src, Dst, *currBldrCtx);
-
for (ExplodedNode *Pred : Src) {
+ const StackFrame *SF = Pred->getStackFrame();
----------------
NagyDonat wrote:
I usually like to declare `SF` and similar "short customary name for an
unchanging piece of the context" variables (which are often used multiple time)
at the very beginning of the function, because their declaration is low
information density bolierplate, and I prefer to have it "out of the way", not
polluting the interesting parts.
Also it is only weakly connected to any one of its usecases, so I don't want to
e.g. place it near the declaration of `SVal V` which happens to be its first
usecase.
--------------------
By the way, on a longer term, after the complete removal of `NodeBuilder`s and
`NodeBuilderContext`, it would be feasible to introduce `const StackFrame *SF`
as a data member of `ExprEngine` (instead of the `StackFrame` currently stored
in `currBldrCtx`) and then we could remove all these boilerplate `const
StackFrame *SF = Pred->getStackFrame();` calls from all methods of `ExprEngine`.
(Note: there is currently a discrepancy between the "current stack frame" of
the ExprEngine and the `->getStackFrame()` of the most recently built
`ExplodedNode` in one location, IIRC in `ProcessCallEnter, but that is
basically a bug. If it is cleaned up, we can consistently use the "current node
builder" of the engine for everything.)
https://github.com/llvm/llvm-project/pull/204371
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
