[cfe-dev] Future of AST transformation

[Sean Silva]

I think the prevailing opinion is that the Clang AST is not meant to
be changed once created. I may be wrong though.

Off the top of my head, some parts of Clang that you might want to
look at are ASTImporter, the AST serialization/deserialization code,
and lib/Sema/TreeTransform.h.

--Sean Silva

On Wed, Jul 18, 2012 at 4:56 AM, Olaf Krzikalla
<Olaf.Krzikalla at tu-dresden.de> wrote:
> Hi @clang,
>
> I'm working at my source-to-source transformator based on clang for
> quite some time now. However, my last clang update constantly causes me
> some serious headaches. Mainly it is the new expr::EvaluateAsRValue
> framework, which asserts like hell. Of course rightly since I cannot
> preserve all - often hidden - AST invariants during transformations.
> Some assertions were fixable, but for a lot of others I have no clue.
> An example: transforming a+=b to a=a+b works like this in my framework:
>
> CompoundAssignOperator* Node;
> // compute binOpc
> Expr* firstRhs = Clone_(Node->getLHS());
> firstRhs->setValueKind(VK_RValue);
> BinaryOperator* TC = Assign_(
>    Node->getLHS(),
>    BinaryOp_(firstRhs, Node->getRHS(), binOpc));
>
> I had to figure out that I had to set the value kind. But in the end
> that was still an easy fix. But recently a new problem popped up:
>
> struct A { float x; };
> A a;
> a.x += y;  // assertion: APValue.h:306: isStruct() && "Invalid accessor"
>
> This comes from the fact that "a" in "a.x" itself is treated as an
> lvalue. And this is only a small example of all the assertion hell I've
> got with the expr::EvaluateAsRValue framework.
> So my question is whether there is or there will be a AST transformation
> framework capable of transforming expressions like above? Or whether
> clang/AST transformation itself is a dead end in the long run?
>
> Best regards
> Olaf Krzikalla
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev