[clang] [analyzer][NFC] Introduce framework for checker families (PR #139256)

[Donát Nagy via cfe-commits]

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