[cfe-dev] Auto-generation of ASTMatchers predicates from source code, proof-of-concept

[Manuel Klimek]

On Sun, Jun 17, 2012 at 9:46 PM, Evgeny Panasyuk
<evgeny.panasyuk at gmail.com>wrote:

>  17.06.2012 22:44, Manuel Klimek wrote:
>
>   I see different approaches to implement such kind of tool:
>> 1. Naive and straightforward way: just as external tool to ASTMatchers,
>> same method that I used in example above. Such approach would result in
>> some "knowledge" duplication, i.e. for each predicate it would be
>> additional some code in predicate-generation tool.
>> 2. More complex way, but with some "knowledge" reuse from ASTMatchers.
>> That approach would require re-describing predicates with some
>> higher/another abstraction, what would allow us to generate both predicates
>> and predicates-generation stuff from one source of "knowledge". I am not
>> sure if such approach could be done in general, requires some research.
>>
>
>  My hunch is that for (2) the matchers would be sufficiently different
> from what they are now, that it would end up like (1) anyway - insert the
> obvious disclaimer that I might be wrong etc etc here :)
>
> Yes, (2) would require re-implementation of matchers in other terms. But I
> think API of matchers will be not changed.
>
>
>   At least for a first step I think (1) is the way to go - once we have
> more experience with how the stuff is used, we can then try to figure out
> how to generalize it...
>
>
> Yes, I fully agree. (1) is a good step to start with, at least for
> prototype.
>
>
>      I don't know whether you're aware, but in the tooling branch there's
>> also a proof-of-concept implementation for dynamic matcher generation, and
>> it might make sense to base your stuff on that.
>>
>>
>>  Are you talking about dynamic parseMatcher (as in ast-query example)?
>>
>
>  Yep, that one...
>
>
> Thank you for note.
>
>
>
>
>>  Or maybe about some interactive (maybe gui) tool for building
>> predicates? I remember that Chandler mentioned about something similar at
>> http://www.youtube.com/watch?v=yuIOGfcOH0k&t=27m56s
>>
>
>  Now we're talking the next step :) Yea, having a GUI would be *great*
> (and just so we're clear: with GUI I mean a web page :P)
>
>
> And maybe AST database optimized for fast predicate matches :)
>

For small projects this might be interesting - for us the question is how
that would scale - we've found parsing the C++ code to be actually an
interesting way to scale the AST, for the small price of needing up 3-4
seconds per TU (on average). Denormalizing the AST itself produces a huge
amount of data, and denormalizing even more seems like a non-starter.

Thoughts?
/Manuel


>
> Best Regards,
> Evgeny
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120617/1982d39c/attachment.html>