On Tue, May 24, 2011 at 10:03 AM, Manuel Klimek <[email protected]> wrote: > On Tue, May 24, 2011 at 8:59 AM, Nico Weber <[email protected]> wrote: >> >> Hi Manuel, >> this looks pretty cool. >> However, as far as I understand, MatchFinder can only be used in stand-alone >> tools using the Tooling infrastructure, because the public api is mostly >> limited to NewFrontendActionFactory(). Do you think it's possible to somehow >> make MatchASTConsumer public as well (maybe just give MatchFinder a >> NewASTCosumer() function), so that the DSL can be used in places were >> ASTConsumers are needed (such as in the "normal" rewriter infrastructure)? I >> only skimmed the patch, so sorry if that's a superficial question. > > Good question. So far I have no idea what the cases would be where > we'd want to use an ASTConsumer instead of a FrontendAction... I'm > currently working on a patch (based on this one) that integrates the > ASTMatcher stuff with the Rewriter to get in-process refactorings - > and so far I've not hit any roadblocks with regard to the > FrontendAction. > Do you have a code example you can point to where an ASTConsumer is required?
Plugins, for example. Chromium's style checker ( http://codesearch.google.com/codesearch/p?hl=en#OAMlx_jo-ck/src/tools/clang/plugins/FindBadConstructs.cpp&q=findbadconstructs.cpp&sa=N&cd=1&ct=rc ) might be able to use the DSL parts if the ASTConsumer is exposed. Anyway, this is a relatively minor point for this patch (and I can't comment on the bigger points :-) ), so I don't want to derail this thread too much. > In general, I'm not completely opposed to make the MatchASTConsumer > public, but slightly wary, as it opens up a bigger intreface (needing > more details about the innards of clang), and I'd like to avoid it > unless there is a compelling use case. > > Cheers & thanks for the feedback, > /Manuel > >> Nico >> >> On Mon, May 23, 2011 at 3:03 PM, Manuel Klimek <[email protected]> wrote: >>> >>> This patch implements an AST matching framework that allows to write tools >>> that match on the C++ ASTs. The main interface is in ASTMatchers.h, an >>> example implementation of a tool that removes redundant .c_str() calls is >>> in the example RemoveCStrCalls.cpp (patch to llvm/clang produced by running >>> this tool will be sent out shortly in an extra email). >>> >>> Currently we have an in-language DSL that allows to write expressions such >>> as (taken from the .c_str() example): >>> ConstructorCall( >>> HasDeclaration(Method(HasName(StringConstructor))), >>> ArgumentCountIs(2), >>> // The first argument must have the form x.c_str() or p->c_str() >>> // where the method is string::c_str(). We can use the copy >>> // constructor of string instead (or the compiler might share >>> // the string object). >>> HasArgument( >>> 0, >>> Id("call", Call( >>> Callee(Id("member", MemberExpression())), >>> Callee(Method(HasName(StringCStrMethod))), >>> On(Id("arg", Expression()))))), >>> // The second argument is the alloc object which must not be >>> // present explicitly. >>> HasArgument( >>> 1, >>> DefaultArgument())) >>> The next steps will be to build up better support for in-process >>> refactorings based on the Rewriter, to build up higher-level matchers for >>> common patterns, and to extend the low-level matcher library. >>> (rietveld link: http://codereview.appspot.com/4552059/) >>> Cheers, >>> /Manuel > _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
