[cfe-commits] [PATCH] AST matchers

[Manuel Klimek]

Ping

(+dgregor, who promised to take a look on irc ;)

On Tue, Jun 19, 2012 at 11:14 AM, Manuel Klimek <klimek at google.com> wrote:

> 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/20120625/f917d868/attachment.html>