NagyDonat wrote:
> I'd recommend you to look at the `Checkers.inc` file in the build folder
> somewhere - the file that gets generated from the `Checkers.td`. Notice that
> every checker has a `registerXXX` and `shouldRegisterXXX` function where XXX
> is the verbatim spelling of the checker class implementing it. We should just
> expose XXX just like we currently expose the similar
> `CheckerManager::getCurrentCheckerName()` (I haven't checked this, its just a
> strong suspicion). We could call this `getCurrentCheckerClassName` or
> something along these lines. This should be 5-10 lines of change
> approximately.
>
> Just have a look at `Checkers.inc` and you will see what I'm talking about.
For a moment I was very happy to see this solution, but unfortunately XXX is
**not** the name of the checker class (= backend = full family), but instead it
is just yet another kind of "internal" name that is assigned to each individual
checker (= frontend = one checker from the family).
You're right that for the simple single-part checkers this kind of name usually
coincides with the checker class name, but it is still not a single name for
the full checker family. For example consider the class `DivZeroChecker` which
implements `core.DivideZero` and `optin.taint.TaintedDiv` -- this is introduced
in `Checkers.td` as
```
let ParentPackage = Core in {
//...
def DivZeroChecker : Checker<"DivideZero">,
HelpText<"Check for division by zero">,
Documentation<HasDocumentation>;
//...
}
let ParentPackage = TaintOptIn in {
//...
def TaintedDivChecker: Checker<"TaintedDiv">,
HelpText<"Check for divisions where the denominator is tainted "
"(attacker controlled) and might be 0.">,
Dependencies<[TaintPropagationChecker]>,
Documentation<HasDocumentation>;
//...
}
```
In this particular case using "debug name = internal name of the _first_
checker part" would work (and it is a core checker so we can say that it won't
be disabled), but if we have a checker family where all the parts are non-core
checkers, then this solution cannot assign a single stable name to the whole
family.
> And thanks again for sticking around. I can understand if this thread already
> got far longer than it should have taken. I admit I failed to give enough
> attention to this thread, and now I'm pushing back because I believe the
> desired solution is right on the corner.
Don't worry about this -- your feedback is valuable (and it's completely
understandable that you also need to work on different things) and I agree with
you that it is important to implement this framework _well_ even if it takes a
bit more time.
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
