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

[Balazs Benics via cfe-commits]

=?utf-8?q?Donát?= Nagy <donat.nagy at ericsson.com>,
=?utf-8?q?Donát?= Nagy <donat.nagy at ericsson.com>,
=?utf-8?q?Donát?= Nagy <donat.nagy at ericsson.com>,
=?utf-8?q?Donát?= Nagy <donat.nagy at ericsson.com>,
=?utf-8?q?Donát?= Nagy <donat.nagy at ericsson.com>,
=?utf-8?q?Donát?= Nagy <donat.nagy at ericsson.com>
Message-ID:
In-Reply-To: <llvm.org/llvm/llvm-project/pull/139256 at github.com>


steakhal wrote:

> Thanks for the patches! I originally thought that renaming `getTagDescription` -> `getDebugName` would be a separate follow-up commit but I see that it's a surprisingly small change (that function was barely used) so I'm happy to include it here.
> 
> I see that your code the status quo by using the name of an arbitrary sub-checker (the one that is registered first) as the debug name of the full checker family. Previously I have tried to avoid this solution because:
> 
>     * this muddies the distinction between the `CheckerFamily` and one of the owned `CheckerFrontend`s (may be a bit confusing for those who are unfamiliar with the analyzer code);
> 
>     * with this solution the same `CheckerFamily` may get a different debug name if different sub-checkers are enabled from it (in that particular run).
> 
> 
> However, if you think that these issues are acceptable, then I'm not opposed to using your solution because I agree that the `__PRETTY_FUNCTION__` hack for using the class name is ugly.
> 

I think the order is deterministic, and due to how checker dependencies are resolved, the backend checker would be always the one that is registered first. I have not checked this. Frankly, I would have preferred if the internal checker class name would be printed there instead of the user-facing name of the checker - but given that I despise defining this for every checker as a mandatory virtual function for checker families, I opted for this solution given my very limited time frame and that I shouldn't block the progress of this PR.

> I also thought about tweaking `CheckerFamily::getDebugName` to produce results like `family-of-core.DivideZero` for checker families (to highlight that it is connected to a checker family and not the particular checker frontend). What would you think about this?

I firmly believe that as this is a debugging feature, the best name to print is the class that gets registered.

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