[all-commits] [llvm/llvm-project] 1a8167: [NFCI][analyzer] Add a clean way to generate nodes...

[Donát Nagy via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 1a81673922a3f5b75f342e416e925a69822c4613
      https://github.com/llvm/llvm-project/commit/1a81673922a3f5b75f342e416e925a69822c4613
  Author: Donát Nagy <donat.nagy at ericsson.com>
  Date:   2026-02-24 (Tue, 24 Feb 2026)

  Changed paths:
    M clang/include/clang/StaticAnalyzer/Core/PathSensitive/CoreEngine.h
    M clang/include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h
    M clang/lib/StaticAnalyzer/Core/CoreEngine.cpp

  Log Message:
  -----------
  [NFCI][analyzer] Add a clean way to generate nodes (#182377)

Currently the most common way for generating nodes is a complicated and
confusing boilerplate approach, which appears in many places:
- A `NodeBuilderContext` is constructed from a `CoreEngine &` and two
other irrelevant arguments.
- A short-lived temporary `NodeBuilder` is constructed from the
`NodeBuilderContext` and some almost irrelevant node sets.
- `NodeBuilder::generateNode()` is invoked once and accesses the graph
through the `CoreEngine &` to generate the node.

To simplify this, I'm cutting out the wrapper layers and extracting the
"main logic" of the method `NodeBuilder::generateNode()` to a new method
called `CoreEngine::makeNode()`. Eventually I intend to replace most use
of `NodeBuilder`s with direct calls to this method.

To ensure that this new `makeNode()` doesn't generate non-sink nodes
with `PosteriorlyOverconstrained` state, I moved the
`isPosteriorlyOverconstrained()` check from `CoreEngine::generateNode()`
to `makeNode()`.

This is technically speaking not an NFC change, because it prevents
`BranchNodeBuilder::generateNode()` from generating non-sink nodes with
`PosteriorlyOverconstrained` state (previously it was able to do so
because it calls `NodeBuilder::generateNodeImpl()` instead of
`NodeBuilder::generateNode()`).

However I labelled this as an NFCI change, as I'm fairly confident that
this won't lead to any observable changes because:
- `PosteriorlyOverconstrained` states are very rare.
- A state derived from a `PosteriorlyOverconstrained` state is also
posteriorly overconstrained, so if `BranchNodeBuilder` fails to sink the
execution path, it will be sunk anyway at the next transition which is
done by a plain `NodeBuilder`.

Note that simulated paths with a `PosteriorlyOverconstrained` state do
not correspond to real paths that can occur during the actual execution
of the program, so the analyzer should stop following them as soon as
possible. For more explanation see the doc-comment above the data member
`bool PosteriorlyOverconstrained` within `ProgramState`.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications