[cfe-commits] [PATCH] call graph building

[Zhongxing Xu]

On Wed, Jul 15, 2009 at 10:37 AM, Ted Kremenek<kremenek at apple.com> wrote:
>
> On Jul 14, 2009, at 6:53 PM, Zhongxing Xu wrote:
>
> On Wed, Jul 15, 2009 at 8:33 AM, Ted Kremenek<kremenek at apple.com> wrote:
>
> On Jul 13, 2009, at 6:31 AM, Zhongxing Xu wrote:
>
> This is an initial implementation of call graph building based on pch
>
> reader and the new Program/Entity facility. It is very primitive but
>
> functional.
>
> Put the files under clang/tools/wpa (meaning 'whole program
>
> analysis'). After 'make', a new command 'clang-analyze' will be
>
> generated. It takes a list of .ast files and build call graph over
>
> them.
>
> Hi Zhongxing,
>
> I would call the program 'clang-callgraph' so that people don't confuse it
>
> with the "static analyzer".  Comments inline.
>
> Hi Ted & Daniel,
>
> My original intention is not to make this a standalone callgraph tool.
> I intend it to gradually become the whole program analysis driver. And
> the first step usually is to build the call graph. Thus I call it
> 'clang-analyzer'.
>
> clang-wpa?  clang-analyzer will really confuse casual users.

clang-wpa sounds good to me.

>
> When CallGraph.h CallGraph.cpp becomes mature enough, I would like it
> to be moved into libAnalysis or elsewhere suitable.
>
> I don't see much of a reason to not include CallGraph.[h,cpp] in libAnalysis
> from the onset and then have the driver use it.  Being in one library or
> another doesn't officially "bless" it as being mature.  For example, C++
> support in Clang isn't fully "mature", but it is spread across the various
> libraries.  Including CallGraph.[h,cpp] in libAnalysis (if that is the
> eventual home) forces you to maintain a library-based design for that class.

Okay. Let's put it in libAnalysis from the onset.