[cfe-dev] Checker Plugins

[Jordy Rose]

Sorry for not responding to this for a month...my mail filters decided to throw away replies that also showed up on cfe lists. I think I have it fixed now...

> I'd personally prefer to move away from static registration for the checker plugins but, instead, use an exported C function that has a "standardized" name. This function will return a CheckerProvider which we can use during checker registration. Moving away from static registration objects gives us much more precise control of the lifetime of CheckerProviders and is more portable (easier to work on windows as well).

The "easier to work on Windows" is the clincher here for me, even though I develop on a Mac!

> Currently the CheckerProvider interface is very minimal and it doesn't enforce any specific naming organization for checkers. I kinda like it this way but then we have the issue of not easily allowing plugins to use the group/package system.

What if we made CheckerProvider instances one-to-one with packages? We could make the osx.cocoa package map to OSX_Cocoa (or osx::Cocoa, but I don't think we want to rely on namespace mangling being consistent). Then we have getCheckerProvider_OSX_Cocoa, or whatever—not particularly pretty, but not hard, either.

It wouldn't be hard to maintain the hierarchy part, either: just include a list of subpackages in the parent provider.

As a bonus, this means that groups and packages can have a single common lookup path, even if we want to keep them distinct in the help output.

The problem with all of this is that loading a plugin won't actually add anything to -analyzer-checker-help without some kind of registration. Maybe that has to stay on llvm::Registry...and once that's true, there's no reason not to make the main CheckerProviders use the same registration.

Alternately, we require a -checker-load (instead of plain -load), which uses the name of the *plugin file* to find the provider in it. Or providers. I guess the CheckerProvider-equals-package proposal is a little orthogonal to the plugin architecture.


> I'd suggest that we provide 2 kinds of examples for plugins.
> 
> One should be in the 'examples' directory and it should do the minimum work necessary to get an example checker plugin up & running (e.g. it will just look for one specific checker string in order to be enabled and it will have a very simple printHelp).
> 
> Apart from that, we create a directory for a dynamically loaded plugin inside the lib/StaticAnalyzer hierarchy that will contain the required [c]make files to allow using the package system. Also we would need to expose some functions from ClangSACheckerProvider.cpp to avoid duplication of registration/help printing when using the package system.

If we can come up with a naming-scheme-based package system, it would probably work for external plug-ins as well as internal ones. Then we can pretty much just make ClangSACheckerProvider into a subclass of CheckerProvider with no customization. Or generate subclasses of CheckerProvider from Checkers.td and ditch ClangSACheckerProvider entirely.

If we pull *current* analyzer plugins (besides LLVMConventionsChecker) into dynamic libraries, how does that affect distribution? Do they go in /usr/lib/clang/checkers, or something?

Jordy



On Jun 4, 2011, at 19:25, Jordy Rose wrote:

> The idea's come up before, right? I feel like having pluggable check-ins is one of the goals of the analyzer, even as everything is refactored over and over. It would be convenient for organizations to make their own API checks, like we do for Unix and Cocoa (a little). Right? Attributes only go so far.
> 
> Anyway, I hacked up a quick plug-in system over the last few days. It approximates Argyrios' very nice group/package system with a poor text-matching version of the registration system, and supports multiple new checkers in one loadable library. <CheckerPlugins.2.patch>
> 
> I'm not suggesting that this is code that should go into trunk now, or even that this is the right approach to checker plug-ins, but I wanted to bring it up again, to see if there's any way to make progress on it.
> 
> (At the very least we'd want some kind of "checker API version" token, so that when we make massive refactorings, we can invalidate old plug-ins.)
> 
> Comments?
> Jordy
> 
> P.S. Why is the static analyzer "ento"? *grin*