[cfe-commits] [PATCH] AST matchers

[Manuel Klimek]

On Tue, Jun 19, 2012 at 10:59 AM, Stephen Kelly <steveire at gmail.com> wrote:

> Manuel Klimek wrote:
>
> > ... one of the final pieces that we have in the tooling branch are the
> AST
> > matchers.
> >
> > The main user interface is in ASTMatchers.h and ASTMatchFinder.h.
>
> Hi,
>
> There are some case mis-matches between documentation and implementation
> with Has/has forEach/ForEach and hasDescendant/HasDescendant,
> forEachDescendant:
>

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 ;)


> +/// Example matches X, Y (matcher = Class(Has(Class(HasName("X")))
> ...
> +template <typename ChildT>
> +internal::ArgumentAdaptingMatcher<internal::HasMatcher, ChildT> has(
>
> Apart from that I think it's a good start. Is it considered experimental or
> 'stable' in any way, or is it allowed to change in any way at all (source
> incompatibly)?
>

We're using it for 1.5 years without significant changes to the API. I
consider it pretty stable at this point.


> I think there may be a need for some more high-level documentation, but
> that
> could also come later if the API is 'experimental' at this point. The scope
> of expected use might also be worth defining.
>

I'm planning to start writing more docs the moment this lands (like I did
for the tooling parts).


> Is it primarily for non-standard, complex problems and one-time-use tools
> (like solving Googles problems), or is it primarily for creation of
> sharable
> tools which can operate on any codebase (like an accurate, medium/long-term
> maintained porting tool or other medium-term maintained tools)?
>

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.

We're also in the process of starting to write sharable tools based on this.


> I consider this a documentation problem because I think there are ways to
> make the tool I created faster by storing information about compilations
> before doing the porting. Currently I use 'git grep' to find potential
>

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.

For llvm I am able to run over all translation units with xargs -n1 -P12
pretty quickly on a 6-core hyperthreading machine.


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

Thanks!
/Manuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120619/672f5ca2/attachment.html>