<div class="gmail_quote">On Fri, Jun 29, 2012 at 10:40 PM, Douglas Gregor <span dir="ltr"><<a href="mailto:dgregor@apple.com" target="_blank">dgregor@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><br><div><div class="im"><div>On Jun 15, 2012, at 5:49 AM, Manuel Klimek <<a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a>> wrote:</div><br><blockquote type="cite">
<div style="font-family:arial,helvetica,sans-serif"><font><div>... one of the final pieces that we have in the tooling branch are the AST matchers.</div><div><br></div><div>The main user interface is in ASTMatchers.h and ASTMatchFinder.h.</div>

<div><br></div><div>Note that the AST matchers are completely independent of the tooling framework, but they are easy to plug into the tooling framework (see ASTMatchersTest.cpp).</div>

<div><br></div><div>(There's also a dynamic way to contruct matchers in the works by Samuel Benzaquen, but it's not included in this patch, as it is a pure addition to the  proposed matcher library)</div><div><br>


</div><div>We've been using the library to drive large scale changes, metrics and analysis internally for > 1 year now.</div></font></div></blockquote><div><br></div></div><div>This is really cool stuff. I have a few comments below, but basically I think it's fine for this to go into the tree. Thank you!</div>
<div class="im"><br><blockquote type="cite"><div style="font-family:arial,helvetica,sans-serif"><font><div>One of the more nit-picky review questions that I don't know what to do about is style:</div>

<div>Matchers are an in-language DSL. We use meta-programming techniques to be able to contruct readable expressions without the need to spell out the types all the time. This leads to the matcher constructions being boths free-standing functions and call-able classes.</div>


<div>Internally, we've used CamelCase with an upper case first letter for the matchers, but I'm fine with changing it either way.</div></font></div></blockquote><br></div></div><div>CamelCase is fine for these. I notice that there's some inconsistency with 'has' names, e.g., hasDescendant vs. HasType.</div>
</div></blockquote><div><br></div><div>Switched to camelCase, as discussed later in this thread an on irc.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div>I'm a little sad that MatchFinder requires me to produce a FrontendAction to actually do the matching, because it feels like unnecessarily coupling. MatchFinder really just needs to be handed an ASTContext and told to "walk this", doesn't it? </div>
</div></div></blockquote><div><br></div><div>Done. ASTMatchers don't depend on Frontend any more. Much nicer now.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div>I see a lot of std::map<std::string, <something>>. Do you actually need the ordering provided by a map, or can you use llvm::StringMap instead?</div></div></blockquote><div>
<br></div><div>As discussed on irc, we copy the maps (recursive algorithm that accumulates the ID -> Node mappings and triggers the callbacks). Until we have a better algorithm, we keep the maps.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div> In general, there are a lot of places where we could/should be using StringRef rather than std::string. Might even help performance somewhat :)</div></div></blockquote><div><br></div>
<div>I've changed all where it was easily possible. The matcher macros still use std::string, as they store the type as members. </div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div>Some of the matcher names are *really* long, and it's going to make uses of the library look more complicated than they should. The use of "Expression" rather than "Expr", for example, avoids name conflicts but is really painful on the eye. Could we just drop the "Expression" suffix in most of those cases, for example? Heck, I'm fine with renaming some of the AST classes if it would make things easier. For example, MemberExpr -> MemberRefExpr would let us just use MemberRef for the matcher.</div>
</div></blockquote><div><br></div><div>Chandler convinced me that we should go into that direction. While converting CamelCase to camelCase I already applied a more AST-like naming scheme to the matchers.</div><div><br></div>
<div>Thanks!</div><div>/Manuel</div></div>