[cfe-commits] r150846 - in /cfe/trunk: lib/StaticAnalyzer/Checkers/CStringChecker.cpp lib/StaticAnalyzer/Checkers/InterCheckerAPI.h lib/StaticAnalyzer/Checkers/MallocChecker.cpp test/Analysis/malloc.c

[Ted Kremenek]

On Feb 22, 2012, at 9:36 AM, Anna Zaks <ganna at apple.com> wrote:

>> (I see that someone on Radar thought the answer was "yes", but...)
>> 
>> Also, separately...is this the way we're going to do inter-checker dependencies? I like how simple it is! And since all the checker registration is done with vectors, it even handles ordering.
> 
> I don't think this handles ordering.. The ordering still depends on the order in which the checkers are defined in the Checker.td file. That's something which needs to be fixed. 
> 
>> But I don't know how it will scale, and it does sort of compel us to expose a registration function for /every/ checker. (Just like warning flags, if we decide it's okay not to have a registration function for some checker, we'll end up in a situation where we need it.)
>> 
> 
> We do not have the dependency mechanism set in stone. We can revisit this later on. I view this approach as something that we can use to define dependencies in special cases. Currently, this is the only dependency we have, though it might quickly change..

Jordy,

To add what Anna said, this solution is what we can work with, and it allows us to explore the kind of behavioral dependencies we would want between checkers.  Doing it this way has serious limitations; for example, if one explicitly disables a checker from the command line, how does it interplay with such dependencies?  What we have is progress towards figuring out what kind of behavioral patterns we need to support as part of expressing checker dependencies, and what that means for the end user.

Ted
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120222/f939c4e0/attachment.html>