On Tue, Jan 15, 2013 at 10:07 PM, Richard Smith <[email protected]>wrote:
> On Tue, Jan 15, 2013 at 1:31 AM, Manuel Klimek <[email protected]> wrote: > > Ping > > > > > > On Tue, Jan 8, 2013 at 1:31 PM, Manuel Klimek <[email protected]> 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
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
