[cfe-dev] Future of AST transformation

[Richard Smith]

On Mon, Jul 23, 2012 at 2:20 AM, Olaf Krzikalla <
Olaf.Krzikalla at tu-dresden.de> wrote:

> Am 21.07.2012 01:08, schrieb Sean Silva:
> > Check out the block comment right above the class declaration, it
> > contains a quite thorough discussion. TreeTransform is just a standard
> > visitor pattern which recursively accumulates the results of
> > subinvocations. If you're familiar with Pythons `ast.NodeTransformer`,
> > TreeTransform is basically the same idea.
> There are at least two reasons against TreeTransform: firstly, it is not
> even exposed as an API but just a part of the sema lib.


Yes, that's unfortunate for your use case, but you should at least be able
to call the relevant Sema::Build* methods directly.


> Secondly, even
> if it would be available, I won't be able to construct an actual object,
> since I don't have a proper sema object. For various reasons I have to
> construct the complete AST before I start transforming it. And then I
> don't have an idea, how I get sema back to the appropriate state.
>

The way to deal with this is to perform your transformation from the
ASTConsumer::HandleTranslationUnit callback. At that point, the entire AST
has been formed, but the Sema object is still alive and ready to do stuff.


> For the moment I'm going to implement my own simple EvaluateAsRValue
> function. Of course I'm very unhappy with this solution right now.


If you want to evaluate ASTs which do not meet the invariants, you will
have to do this. There are also no guarantees that AST printing, or any
other AST functionality (including creating the AST nodes in the first
place), will work on invariant-violating ASTs.

-- Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120723/b9175b1b/attachment.html>