<div dir="ltr"><div class="gmail_default" style>Ping</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 8, 2013 at 1:31 PM, Manuel Klimek <span dir="ltr"><<a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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>
<a href="http://llvm-reviews.chandlerc.com/D267" target="_blank">http://llvm-reviews.chandlerc.com/D267</a><br>
<br>
Files:<br>
  include/clang/AST/ASTContext.h<br>
  include/clang/ASTMatchers/ASTTypeTraits.h<br>
  lib/ASTMatchers/ASTMatchFinder.cpp<br>
</blockquote></div><br></div>