[cfe-dev] Patch: AST Matcher Framwork and an example tool

[Chris Lattner]

On Jun 14, 2011, at 11:21 PM, Manuel Klimek wrote:
>> Considering that we want to eventually get a dynamic pattern matching language, but we also want to get it right, we are currently spending our time on the in-language DSL, and especially for the large scale stuff the developers we work with need surprisingly little help (the included example for replacing reduncant c_str() calls was created by a contributor who's not worked on the implementation of the matcher library).
> 
> I'm not sure I get this logic.  You're saying that you're afraid you won't get the matching language right, so you'd avoiding it and doing something you know is wrong ;-).  I expect much iteration on this, but all that requires is to tell people to expect breakage as you get experience with it and evolve things.
> The main problem with building a dynamic language is that it's significantly more effort, as it will require to be a lot more complete before being useful.

While this is true, "doing the right thing is hard" isn't a good excuse for doing the wrong thing :).  I know this isn't what you're actually saying, but it's better (to me at least) to try to understand the long term direction and then figure out incremental steps to get there.  It's generally easier to motivate things if you say that this is a step in the right direction.

> I don't think our current code is "wrong". I think it is useful for a certain amount of tools, and as the basis of more dynamic tools.

Ok, I agree with you here.  I think that the compile-time pattern matching could be very useful, for a broad variety of clients.  Many warnings in the compiler are implemented by effectively pattern matching on ASTs, and it would be much more nice to use a pattern matching style API instead of a manual tree walk.  These should clearly be statically compiled into the binary.

> 2. You're building substantial new functionality into clang.  The clang binary is already overly bloated with the static analyzer and other functionality that it keeps accreting .  It would be better to use (and improve) the clang plugin mechanism to build this as a plugin.  I'd also like the analyzer to move off to being a plugin as well.  One carrot that we can give for people to build things as plugins is that they can use C++'0x features even though the clang compiler has to stay C++'98 for the forseeable future. 
> 
> The point why I don't want to run tools as a plugin is that the command line syntax for tools can be significantly different from running the compiler. I don't think this needs to be linked into the clang binary though - as nothing in clang depends on it (confused...)

Ok, I think that the root of the issue is that the patch just has too many different things going on.  I'm still dubious about the tooling infrastructure, but the pattern matching functionality is clear goodness.

How about we start with *just* the AST pattern matching APIs, iterating on them until we get to something that can go in, with some warnings switched over to using it as an example.  As a step towards this, please take a look at include/llvm/Support/PatternMatch.h, which does pattern matching on LLVM IR.  I'd prefer the clang matching API to look more similar to it.

Thanks Manuel, again I really appreciate you pushing this functionality forward,

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110617/b5f55bcc/attachment.html>