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

[Zhongxing Xu]

On Tue, Aug 4, 2009 at 9:24 AM, Zhongxing Xu<xuzhongxing at gmail.com> wrote:
> On Tue, Aug 4, 2009 at 2:08 AM, Ted Kremenek<kremenek at apple.com> wrote:
>> On Aug 2, 2009, at 8:13 PM, Zhongxing Xu wrote:
>>
>> Author: zhongxingxu
>> Date: Sun Aug  2 22:13:46 2009
>> New Revision: 77943
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=77943&view=rev
>> Log:
>> Create only one AnalysisManager for each translation unit. In HandleCode(),
>> reset the current analysis context of the AnalysisManager.
>>
>> Hi Zhongxing,
>> I was thinking about this, and is there a reason that AnalysisManager needs
>> to know about the current analysis context?  To me the notion of a "current
>> context" seems limited and unnecessary.  When we start analyzing a function
>> or method, can we not simply create an AnalysisContext on-the-fly that
>> references AnalysisManager?
>
> I think this is the goal. We can pass the entry Decl* to
> ActionGRExprEngine() and create the AnalysisContext on-the-fly.
>
>> 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. Then AnalysisManager,
GRExprEngine, GRStateManager, and BugReporters can be Decl
independent. They can get local context from the ProgramPoint.

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