[cfe-dev] [RFC] Dynamic AST Matcher library

[Samuel Benzaquen]

On Wed, Dec 5, 2012 at 3:08 PM, Sean Silva <silvas at purdue.edu> wrote:

> On Wed, Dec 5, 2012 at 12:09 PM, Samuel Benzaquen <sbenza at google.com>
> wrote:
> > Full C++ expression support for predicates. Values are going to be
> limited
> > to literals (eg. 1, “foo”). Expressions like 1+2 will not be parsed. Some
> > useful constants (like INT_MAX) might be available
>
> This almost seems like an indictment of clang. Isn't the whole point
> of clang that we have a library which is capable of doing this?
>

True. You could use clang itself to parse it.
For the proof-of-concept having a simple parser seemed easier.


> It seems like the fundamental issue that the dynamic matchers are
> trying to address is the long iteration time required by recompile.
>

There are two use cases for the dynamic matchers:
 - Faster development time for someone creating matcher expressions for a
specific purpose.
 - Generic services that accept arbitrary matchers at runtime. Eg. a
grep-like tool that uses matchers instead of regex.

The latter was my main motivation for this work.


> Effectively, the dynamic matcher infrastructure would then simply be
> special purpose compiler for a subset of C++ with hardcoded semantics
> just enough to support the ASTMatchers. That really seems like a
> band-aid.
>

I think you are referring to the parser here, which is the one that is
limited to declarative matcher expressions.
The rest of the library (variant type, registry, etc) allows runtime
generation of arbitrary matchers. This can be used independently of the
parser if the generation of the expression is done in some other way.


>
> There has been quite a bit of work around speeding up this iteration
> loop using clang. The big one I can think of is cling
> <http://root.cern.ch/drupal/content/cling>. There is also an IDE (I
> think intended for game development) which uses Clang+JIT to
> dynamically run and recompile programs (e.g. you can change a constant
> in the source which represents a color, and in real time the running
> program reflects this change). There is even the relatively
> unmaintained examples/clang-interpreter which, while being quite crude
> and not feature-complete, is a remarkably short proof of concept.
>

I'll look into JIT'n the matchers.
It could be a simpler solution for the problem.

_Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121205/4b045c8c/attachment.html>