[cfe-dev] CallGraph and TranslationUnits

Zhongxing Xu xuzhongxing at gmail.com
Wed Oct 28 05:25:43 PDT 2009


Hi Simone,

The patch is applied. Next time would you please generate patch with
'svn diff'?

2009/10/28 Simone Pellegrini <spellegrini at dps.uibk.ac.at>:
> Hello,
> I have created a patch that could make the use of CallGraph more flexible.
>
> The main idea is that CallGraph doesn't need to depend from ASTUnit as what
> it is needed to build the call graph is the ASTContext (which can come from
> either and ASTUnit or a TranslationUnit).
>
> cheers, Simone
>
> Zhongxing Xu wrote:
>>
>> Hi Simone,
>>
>> I wrote the current implementation of callgraph months ago as an
>> experimentation. It's not meant to be a stable interface. If you have
>> more general interface or better implementation, patches are welcome.
>>
>> - Zhongxing Xu
>>
>> 2009/10/25 Simone Pellegrini <spellegrini at dps.uibk.ac.at>:
>>
>>>
>>> Dear all,
>>> the clang::CallGraph class allows to build call graphs, by using the
>>> method addTU(ASTUnit&), starting from clang::ASTUnit object which (as
>>> far as I understand from the API) are normally generated from PCH files .
>>> However, someone ( like me for example :) ) would like to build
>>> CallGraphs starting from instances of clang::idx::TranslationUnit class
>>> and the current API doesn't allow that. :(
>>>
>>> If you look to the implementation of the addTU(ASTUnit&) method there is
>>> no reason why it couldn't be possible to built a CallGraph starting from
>>> a TranslationUnit object. What the method does is looking for the
>>> ASTContext, and TranslationUnit objects have the same getASTContext()
>>> method.
>>>
>>> I think there is a little bit of confusion about the API. Right now it
>>> seems to be that there are two kinds of TranslationUnits (1 coming from
>>> PCH files and another used by the Indexer for indexing entities) and
>>> there is no homogeneous way to handle this 2 objects as they have no
>>> common ancestors. Why the getASTContext() method both in ASTUnit and
>>> TranslationUnit is not factorized into an interface? this will make
>>> CallGraph.addTU() more generic. Or, if possible, having ASTUnit
>>> implementing the TranslationUnit interface (I don't know whether there
>>> is any conceptual reason that prevent ASTUnit to be a TranslationUnit).
>>>
>>> For the moment I was able to solve the problem by slightly changing the
>>> CallGraph interface by introducing the add(clang::ids::TranslationUnit&)
>>> method and by factorizing the implementations with a call to a private
>>> method addAST(ASTContext&). I think things will be even easier if the
>>> CallGraph is built starting from ASTContext.
>>>
>>> Am I missing something?
>>>
>>> regards, Simone P.
>>>
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>
>>>
>
>



More information about the cfe-dev mailing list