<div style="font-family: arial, helvetica, sans-serif"><font size="2"><div class="gmail_quote">On Tue, Jun 19, 2012 at 10:59 AM, Stephen Kelly <span dir="ltr"><<a href="mailto:steveire@gmail.com" target="_blank">steveire@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">Manuel Klimek wrote:<br>
<br>
> ... one of the final pieces that we have in the tooling branch are the AST<br>
> matchers.<br>
><br>
> The main user interface is in ASTMatchers.h and ASTMatchFinder.h.<br>
<br>
</div>Hi,<br>
<br>
There are some case mis-matches between documentation and implementation<br>
with Has/has forEach/ForEach and hasDescendant/HasDescendant,<br>
forEachDescendant:<br></blockquote><div><br></div><div>Yep, this is a known problem, and related to the bikeshedding about whether we want the matcher creator functions to be lower-case or upper-case first letter. I don't want to switch back and forth a few times, so I'd like to get a decision, switch to that decision, and clean up all references ;)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+/// Example matches X, Y (matcher = Class(Has(Class(HasName("X")))<br>
...<br>
+template <typename ChildT><br>
+internal::ArgumentAdaptingMatcher<internal::HasMatcher, ChildT> has(<br>
<br>
Apart from that I think it's a good start. Is it considered experimental or<br>
'stable' in any way, or is it allowed to change in any way at all (source<br>
incompatibly)?<br></blockquote><div><br></div><div>We're using it for 1.5 years without significant changes to the API. I consider it pretty stable at this point.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

I think there may be a need for some more high-level documentation, but that<br>
could also come later if the API is 'experimental' at this point. The scope<br>
of expected use might also be worth defining.<br></blockquote><div><br></div><div>I'm planning to start writing more docs the moment this lands (like I did for the tooling parts).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Is it primarily for non-standard, complex problems and one-time-use tools<br>
(like solving Googles problems), or is it primarily for creation of sharable<br>
tools which can operate on any codebase (like an accurate, medium/long-term<br>
maintained porting tool or other medium-term maintained tools)?<br></blockquote><div><br></div><div>Both :) For the complex problems it's pretty much "good to go as is", as the productivity of creating the tool is often not the biggest concern - getting the changes tested and checked in uses up much more of an engineer's time.</div>
<div><br></div><div>We're also in the process of starting to write sharable tools based on this.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I consider this a documentation problem because I think there are ways to<br>
make the tool I created faster by storing information about compilations<br>
before doing the porting. Currently I use 'git grep' to find potential<br></blockquote><div><br></div><div>Well, at Google we just use more cores. I am aware that that's not a good solution for everybody, and am open to suggestions.</div>
<div><br></div><div>For llvm I am able to run over all translation units with xargs -n1 -P12 pretty quickly on a 6-core hyperthreading machine.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

porting cases, which means that I might needlessly be compiling certain TUs<br>
multiple times because of a text match but not a semantic match.<br>
<br>
<a href="https://github.com/KDAB/Qt4to5/blob/master/portqt4to5.py" target="_blank">https://github.com/KDAB/Qt4to5/blob/master/portqt4to5.py</a><br>
<br>
I think this is something Chandler also mentioned there was a solution for<br>
in his talk (that Google records lots of information from compiles).<br>
<br>
I don't expect all of that to be in this patch of course, but it would be<br>
interesting to confirm that that's the kind of things that are in scope and<br>
can be added in the future.<br>
<br>
Given the extensive comments, unit tests, and the fact that I've also used<br>
this API a bit, I support applying this patch.<br></blockquote><div><br></div><div>Thanks!</div><div>/Manuel </div></div></font></div>