NagyDonat wrote:
## Accommodating the modeling checkers in the checker family framework
_I thought a bit about the place of the modeling checkers in the checker family
framework (which is introduced in this PR). This question is a bit
architectural, so in theory this post would "belong to" discourse, but I'm
posting this here because I don't want to fragment the discussion._
As far as I see currently the modeling checkers can fulfill two purposes:
- (1) If a checker class provides a modeling checker, it is a common dependency
of the frontend/reporting checkers from the same family; so the registration
function of the modeling checker can serve as the canonical place for
constructing the singleton instance of the checker class.
- _(This is no longer needed in the new checker family framework.)_
- (2) Some modeling checkers are also dependencies of "external" checkers (i.e.
checkers that are not from the same family) and they provided a way to enable
the backend without enabling any of the frontend/reporting checkers.
- _(We will still need something like this in the new framework.)_
Unfortunately the modeling checkers were introduced gradually in an ad hoc
fashion, so this architecture has several drawbacks:
- adding a modeling checker requires verbose boilerplate in `Checkers.td` and
the checker source file;
- there are checker families that don't have an associated modeling checker;
- modeling checkers were introduced as "like a regular checker, but hidden", so
they have vestigial remains of user-facing features (e.g. they have a
user-friendly name, they can have checker options) that are no longer relevant
for them.
### "Default" plan
In my opinion this is the best and least disruptive way for handling the
modeling checkers in the "checker family" framework:
- Modeling checkers that are only relevant for purpose (1) are simply removed
from the codebase. They are just implementation details of the old checker part
registration process and the new framework makes them redundant.
- The few modeling checkers that are also relevant for purpose (2) "survive"
without serious changes: they become `CheckerFrontend`s within their
`CheckerFamily` and other checkers can specify them as dependencies (but they
are hidden from the user).
- The format of `Checkers.td` stays the same -- only specifies data about the
checker _frontends_, it is not aware of checker families and the "from the same
family" relationships.
This approach avoids disruptive changes and eliminates a significant amount of
boilerplate code (all the superfluous checker families).
### Alternative plan
1. We rename `CheckerFrontend` to `ReportingChecker` and `CheckerBackend` to
`ModelingChecker`.
2. Extend the format of `Checkers.td` to support three kinds of checker
entities:
- `ModelingChecker`s that have a debug name and can be activated as
dependencies (and probably they can also _have_ dependencies);
- `ReportingChecker`s that have a user-facing name, can be enabled or
disabled by the user, can have checker options and depend on one or more
`ModelingChecker`s;
- `Checker`s which are just a shortcut for introducing a `ModelingChecker`
and a single `ReportingChecker` that depends on it.
3. Adding a new plain checker is mostly unchanged: it is implemented as a
subclass of `Checker<...>` and it's specified in `Checkers.td` as a `Checker`
object.
- In this architecture even these simple checkers have separate modeling
and reporting "parts" (at least in theory), so they should support activating
their modeling part (as a dependency) without enabling their reporting part --
but this could be implemented within the engine if we say that bug reports
created by a disabled `ReportingChecker` are automatically suppressed (treated
as invisible sink nodes).
4. Adding a new checker family requires a bit more boilerplate compared to the
default plan: in addition to implementing it (as a subclass of
`CheckerFamily<...>`) and describing its sub-checkers with `ReportingChecker`
entries in `Checkers.td`, the developer also needs to create a
`ModelingChecker` entry in `Checkers.td` (which specifies the debug name of the
family and acts as a common dependency of the `ReportingChecker`s).
5. Limitation: this doesn't support having two distinct modeling checkers
within the same implementation class.
This approach would be more disruptive (we'd need to change the parsing of
`Checkers.td` and the way of handling dependencies) and and increase the amount
of boilerplate (instead of the "each checker family needs a `getDebugName`
method" requirement we'd get the requirement that "each checker family needs
its own `ModelingChecker` entry in `Checkers.td`"), but would clarify the
distinction between modeling and reporting checkers.
@steakhal @ anybody else What do you think about this question? How would you
integrate modeling checkers into the checker family framework?
https://github.com/llvm/llvm-project/pull/139256
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
