[cfe-dev] Adding support for Cloning in the AST
Sebastian Redl
sebastian.redl at getdesigned.at
Sun May 24 04:47:35 PDT 2009
moataz ragab wrote:
>
>
> On Sat, May 23, 2009 at 3:46 PM, Sebastian Redl
> <sebastian.redl at getdesigned.at <mailto:sebastian.redl at getdesigned.at>>
> wrote:
>
> Douglas Gregor wrote:
> >
> > On May 19, 2009, at 7:18 PM, moataz ragab wrote:
> >
> >> Whether it might be useful or not to clone a declaration, it
> might be
> >> useful if you want to create a new variable declaration similar to
> >> another declaration and only change the name.
> >
> >
> > Hmmm, interesting. It seems to me like we really want to give the
> > expression's Clone method some information that tells it what to do
> > with declarations. For your loop-unrolling rewriter, we want to
> > replace some variable declarations with other, similar variables
> > (e.g., when the original variable was declared in the loop) or reuse
> > the same variable declaration (if the variable is declared
> outside the
> > loop).
>
>
> For the loop unrolling rewriter, I was thinking about skipping the
> declarations in loop body and replace them with an assignmen if they
> were initializing the variable. I planned to stop the cloning at this
> level and make the expression point to the same declaration.
> It doesn't come to my mind a case where I would need to declare
> another variable. Please correct me if I am wrong?
>
It's wrong in the case of C++ where initialization and assignment can
really differ. Sometimes one is possible, and the other isn't. The
simplest case is where the variable in question is a reference.
>
> A callback to handle all sub-objects, instead of just cloning
> recursively? It would be very tricky to do as a "policy" that is
> anything less than a fully generic callback, given that cloning is
> deep.
> The callback has to handle everything in that part of the AST somehow.
> You can't stop at a single level.
>
> What do you think about passing a visitor to Clone()?
It's probably what passing a callback comes down to.
Sebastian
More information about the cfe-dev
mailing list