[cfe-commits] [PATCH] First step towards adding a parent map to the ASTContext.

[Manuel Klimek]

On Tue, Jan 15, 2013 at 10:07 PM, Richard Smith <richard at metafoo.co.uk>wrote:

> On Tue, Jan 15, 2013 at 1:31 AM, Manuel Klimek <klimek at google.com> wrote:
> > Ping
> >
> >
> > On Tue, Jan 8, 2013 at 1:31 PM, Manuel Klimek <klimek at google.com> wrote:
> >>
> >> This does not yet implement the LimitNode approach discussed via email,
> >> but I want to get some opinions in what that interface should look like
> >> and how we'd want it to behave. If there's agreement that this is
> >> generally desirable, I'll pull the ASTTypeTraits into AST/.
> >>
> >> The impact of this is an O(n) in the number of nodes in the AST
> >> reduction of complexity for certain kinds of matchers (as otherwise the
> >> parent map gets recreated for every new MatchFinder).
> >>
> >> Open questions:
> >> - if we implement a second version with a LimitNode, do we want to cache
> >>   those results at all (it's hard, because of the
> >>   multiple-parents-problem).
> >> - do we want to leave the RAV implementation in ASTContext (which is
> >>   already large), or pull it out into an ASTContextInternal header (or
> >>   similar)?
> >> - this introduces ast_type_traits::DynTypedNode into a more prominent
> >>   location - if there's problems with that approach, now is the time to
> >>   point it out to me :)
>
> Could we avoid having multiple parents by providing the containing
> Decl as context?
>

How do you define "containing decl"? Innermost containing decl?

But, I also think it doesn't really matter - for any arbitrary "containing
node", we can implement hasParent, but we'll probably want a very different
kind of caching (that's one reason why I haven't added this interface yet).

For the use case of the ast matchers, we generally do not know a containing
decl. The user says "find me all nodes X whose parents fulfill Y" - those
are the ones where caching is very important.

Cheers,
/Manuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130116/a2f7851e/attachment.html>