[clang] [NFC][analyzer] Remove the NodeBuilder from eagerly assume (PR #204371)

[Donát Nagy via cfe-commits]

================
@@ -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