[cfe-dev] Checker Plugins

[Ted Kremenek]

Hi Jordy,

I think this looks pretty awesome.

My only initial concern is the code in:

+//===----------------------------------------------------------------------===//
+// Printing Help.
+//===----------------------------------------------------------------------===//
+

which your own comments indicate are largely "copied" from elsewhere.  If we could refactor that somehow, or better yet, get the plugin mechanism out of the business of printing anything and just provide declarative information that could be used by centralized command line processing that would be a much better strategy.

Other than, this looks great.  I'd very much encourage getting something into mainline soon for us to play with.

Thanks for working on this!

Ted

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