[clang] [NFC][analyzer] Framework for multipart checkers (PR #130985)

DonĂ¡t Nagy via cfe-commits cfe-commits at lists.llvm.org
Sun Mar 16 09:31:58 PDT 2025


NagyDonat wrote:

> I'm somewhat unsatisfied, but it's not because of this PR. This is an excellent way forward, I just wish we had a better abstraction.

I agree that the architecture that's being formalized by this commit is not perfect.

If I would be reimplementing a static analyzer from zero, I would probably separate:
- small "Reporter" classes which
  - have a user-facing name,
  - can be enabled/disabled by the user,
  - have `reportBug(...)` methods that produce a bug report if the Reporter is enabled;
  - implement unique logic (e.g. message formatting) that is only relevant for one sub-checker;
- big "Modeler" classes which
  - own one or several (or perhaps zero) Reporters,
  - are active if any of their Reporters is enabled (or if some other Modeler depends on them),
  - implement various callbacks (`check::XXX`, `eval::Call` etc.) and update the `State` and call `MyReporter::reportBug(...)` methods from these callbacks;
  - implement the shared logic of a group of related Reporters (i.e. what is currently represented by a single multipart checker class).

However, given the existing codebase I don't think that it's feasible to suddenly switch to an architecture like this. However, we could gradually approach this transition, e.g. if we gradually replace `CheckerNameRef` with a richer and more complex class that can become our `Reporter`.

https://github.com/llvm/llvm-project/pull/130985


More information about the cfe-commits mailing list