[cfe-dev] Checker Plugins

[Argyrios Kyrtzidis]

Hi Jordy,

Thanks for getting the initiative to start work & discussion on it.
Here's my thoughts on it, let me know what you think.

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).

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.
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.
This lib/StaticAnalyzer plugin will, at least, contain the LLVMConventionsChecker. Not sure if OSX/Cocoa should move to a plugin eventually but at least getting the 'LLVM' package into a plugin would be a good first step.

Thoughts ?

On Jun 4, 2011, at 7:25 PM, 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*_______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev