[cfe-dev] Creating single AST for multiple files

[James Dennett]

On Thu, Jan 15, 2015 at 12:51 PM, Deepak Rajendrakumaran <deepak3 at vt.edu>
wrote:

> Hello,
>
> I am new to Clang and so I am having some problem figuring out how to
> create AST for a program with multiple files .
>
>
> What I am trying to do:
> - In an application containing multiple .cpp/.c and .h files, parse
> through all the files and identify all instances of a particular function
> -Move the function definition to a new file with a changed name(changed
> function name)
> -Find all instances where the particular function is called and change the
> function name to the new name
>
> (I am ignoring the other dependencies like nested functions/headers etc so
> that I can focus on my actual question. So assume this works:))
>
> I have been reading up on Clang/libtooling inorder to figure out a way to
> do the same. From what I understand, the steps to do this would be
> - Compile and create ASTs for the entire source code(assuming it includes
> multiple .cpp and .h files)
> -Somehow traverse these ASTs(RecursiveASTVisitor)  to figure out where all
> this the particular function I am interested in exists(ASTMatchers??)
> -First write the function definition to a new file
> -Now use the rewriter to write the original file without the function
> definition and replace all the places where a call to this function exists
> with its new name
> (I have tried to simplify the problem statement so that I can pinpoint my
> issue better. I'll ofcourse have to manipulate the ASTs and the source code
> more to get a working program )
>
> First of all, I need to have ASTs of all TUs and not just one AST. Is
> there any way in libtooling to obtain a single AST for multiple TUs? If not
> is there any standard practice for the same incase anyone has faced the
> same problem?
>
>
I'm not sure that I understand.  Standard practice is to process one AST
per TU.  I've not found it to be a problem, but maybe it is for you for
some reason -- in which case it might help to say what that reason is.
There may well be solutions.

-- James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150115/37488e99/attachment.html>