[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