<div dir="ltr"><div class="gmail_default" style>On Tue, Jan 15, 2013 at 10:07 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br></div>
<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Tue, Jan 15, 2013 at 1:31 AM, Manuel Klimek <<a href="mailto:klimek@google.com">klimek@google.com</a>> wrote:<br>

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