[cfe-commits] r77943 - in /cfe/trunk: include/clang/Analysis/PathSensitive/AnalysisManager.h lib/Frontend/AnalysisConsumer.cpp

[Ted Kremenek]

On Aug 3, 2009, at 11:59 PM, Zhongxing Xu wrote:

>>> Ideally, we want a nice separation between the management of  
>>> analysis data
>>> and the driving of analysis logic.  This reduces complexity,  
>>> potential bugs,
>>> and also enable us to make AnalysisManager reentrant.  For  
>>> example, I see no
>>> reason why a single AnalysisManager couldn't be used to analyze  
>>> multiple
>>> functions in parallel, especially if its main task is to manage  
>>> data.
>>> Ted
>>
>
> I think this can only be enabled after the ProgramPoint is extended to
> include the LocationContext information.

Hi Zhongxing,

I honestly don't think this is a prerequisite.  While an analysis  
needs the notion of the current "decl", the AnalysisManager does not.   
The logic that drives the analyses needs the notion of a current decl,  
but that could be a local variable in a method call of AnalysisManager  
(for example).  I imagine that whatever creates a GRExprEngine object  
or calls the entry point of an "analysis" will need to construct a  
LocationContext object and pass it to the analysis.

> Then AnalysisManager,
> GRExprEngine, GRStateManager, and BugReporters can be Decl
> independent. They can get local context from the ProgramPoint.

Not all analyses will be using ProgramPoints.  I think the lowest  
common denominator here is LocationContexts.  For example, flow- 
insensitive checks will not even need the CFG, the DataflowSolver, or  
GRExprEngine.  We need a solution that works for all checks.

I don't believe that AnalysisManager needs to (or should) care about  
ProgramPoints.  It cares about (context-sensitive) analysis data.   
ProgramPoints are used to index within a method or function body.  Put  
another way, ProgramPoints represent specific locations, and  
LocationContext represents context for those locations.  It seems that  
AnalysisManager only needs to reason about the latter.  What do you  
think?

> And before extending the ProgramPoint, I'd like to tidy up the
> template gross of ExplodedGraph, ExplodedNode, and various
> stmtbuilders.

I agree that this cleanup is needed, but I don't see it as a blocker  
other than there is a ton of code that could be cleaner.  I'm not  
opposing that we clean that up, I'm only raising the point because  
that cleanup will require some effort and a fair amount of testing  
since it involves refactoring the analysis core itself.  I think this  
cleanup should happen incrementally, allowing us to incrementally test  
the cleanup as well as gradually bring in new features.