[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:

> I agree, but unfortunately there is no way to get the class name automatically in a platform-independent way without a third-party dependency like [the type_name boost library](https://www.boost.org/doc/libs/master/libs/core/doc/html/core/type_name.html). (Do I understand it correctly that we cannot just drop in an external dependency like this?)
> 
> Using the name of one subchecker is probably the least bad available approach and your code is an elegant implementation for it, so I'll probably apply it to get this PR merged. If you're not opposed, I would like to add a `family-of-` prefix to the debug names, which is a bit awkward but eliminates the ambiguity and the potential for confusion (somebody who briefly looks at some debug output will immediately see that the name identifies the _family_).

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.

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.

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