[cfe-dev] Student of prof. Reichenbach with questions on clang ast

Krishna Narasimhan krishna.nm86 at gmail.com
Thu Jan 23 07:03:03 PST 2014

Thanks a lot Klimek,

The reason I primarily wanted an AST transformation was the inherent issues
with co dependent multiple transformations.

For eg, lets say there is a node A which i just transformed and a
predecessor node B which needs to be transformed based on the transformed
version of A, i might need to include that transformed A node somewhere or
flag it appropriately right?
I will look into that issue

About the macros. Are there any specific code locations I could look at to
get this preprocessed token streams to make sense of the macros?

P.S: I have included the clang mailing list.  :-)

---------- Forwarded message ----------
From: Manuel Klimek <klimek at google.com>
Date: Thu, Jan 23, 2014 at 1:12 PM
Subject: Re: Student of prof. Reichenbach with questions on clang ast
To: Krishna Narasimhan <krishna.nm86 at gmail.com>

On Thu, Jan 23, 2014 at 1:08 PM, Krishna Narasimhan
<krishna.nm86 at gmail.com>wrote:

> Hi, I am a student of Prof. Dr. Reichenbach .
> I have two questions regarding Clang(which I plan to use for my
> transformations):
> 1) How do i perform a transformation on the AST. I see that it is
> immutable. Are there support in Clang for this or external tools?
Nope. It's hard to change a C++ AST in a way that doesn't break its
invariants. What we prefer to do (and for which tools exist) is to use the
AST to figure out which code to change, and then change the code
(textually). Clang has very good support for finding out what code models
which part of the AST.

> 2) Is there a way to prevent the pre processing (or rather) a way to
> modify an AST that is not the pre processed version of the program. For eg,
> if i want to refactor a #define, i currently have no way. Or?
Again, no. But Clang's preprocessed token stream has all information to see
how macros are expanded, so you *can* refactor a #define.

In general, I'd suggest you always include clang's developer mailing list
(cfe-dev) when asking such questions, as they're often interesting for
other people ;)


I dare do all that may become a man; Who dares do more, is none - Macbeth,
twelfh night!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140123/055b0783/attachment.html>

More information about the cfe-dev mailing list