[cfe-dev] Toward the AST cloning

[moataz ragab]

On Fri, Jun 5, 2009 at 1:11 PM, Olaf Krzikalla <Olaf.Krzikalla at tu-dresden.de
> wrote:

> Hi @all,
>
> while my AST XML patch still seems to be in the pipeline (I hope it is in
> someones pipeline) I worked on at AST level
> source-to-source-transformations. Quickly I came at the point where I need
> the AST cloning feature too which was already discussed here. However I
> choosed a non-intrusive approach using the StmtVisitor. I attached a almost
> working sketch (it's a cut-out, just add the includes and namespaces and
> yes, I know, the DenseMap again :-). The advantage is that you get a mapping
> between original and cloned AST nodes (in a productive version this would be
> an optional feature), which is needed for rechaining gotos to cloned labels,
> DeclRefs to other variables aso. Indeed someone could compute such a mapping
> by hand but this would be overly complex and needs to traverse the AST a
> second time.
> As you can see, the decl-cloning issue isn't resolved yet. I will work on
> it next week.
> Opinions? Suggestions?


I like the idea of non-intrusive approach. However, IMHO, I don't think that
it always have to be non-intrusive. I think the clone should be part of the
API of the AST nodes. When I look at a clone function, I expect that the
object from which clone is called is the one that is cloned. In the
non-intrusive approach, the clone is called from the visitor.

One solution to the last point is to rename the method in the visitor from
Clone to something like doCopy.
Or the Clone can just be implemented in the AST nodes and pass it a visitor.

On the declaration statements/ declaration references, it might be important
in some cases when the declaration is local to rename the variable and all
references to it. or replace the declaration statement with another
statement. I suggest that a configuration object to be passed to the
visitor.


Moataz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20090608/7162c8f6/attachment.html>