<div dir="ltr">On Wed, May 8, 2013 at 4:38 PM, Vane, Edwin <span dir="ltr"><<a href="mailto:edwin.vane@intel.com" target="_blank">edwin.vane@intel.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<br>
> -----Original Message-----<br>
> From: Vane, Edwin<br>
> Sent: Wednesday, May 08, 2013 10:26 AM<br>
> To: 'Pedro Delgado Perez'; <a href="mailto:klimek@google.com">klimek@google.com</a>; <a href="mailto:kozargabor@gmail.com">kozargabor@gmail.com</a><br>
> Cc: <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
</div><div class="im">> Subject: RE: [cfe-dev] ASTMatchers: isVirtual and isOverride<br>
><br>
><br>
><br>
> > -----Original Message-----<br>
> > From: Pedro Delgado Perez [mailto:<a href="mailto:pedro.delgadoperez@mail.uca.es">pedro.delgadoperez@mail.uca.es</a>]<br>
> > Sent: Tuesday, May 07, 2013 8:22 AM<br>
> > To: <a href="mailto:klimek@google.com">klimek@google.com</a>; Vane, Edwin; <a href="mailto:kozargabor@gmail.com">kozargabor@gmail.com</a><br>
> > Cc: <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
</div><div class="im">> > Subject: RE: [cfe-dev] ASTMatchers: isVirtual and isOverride<br>
> ><br>
> > Hi again,<br>
> ><br>
> > Sorry to make so much questions, but I hope a good structure of my<br>
> > tool will save me a lot of time in future.<br>
> ><br>
> > I'm using something like this in<br>
> > <a href="http://clang.llvm.org/docs/LibASTMatchersTutorial.html" target="_blank">http://clang.llvm.org/docs/LibASTMatchersTutorial.html</a>:<br>
> ><br>
> ><br>
> > class LoopPrinter : public MatchFinder::MatchCallback {public : virtual void<br>
> > run(const MatchFinder::MatchResult &Result) { if (const ForStmt *FS =<br>
> > Result.Nodes.getNodeAs<clang::ForStmt>("forLoop")) FS->dump(); }};<br>
> ><br>
> ><br>
> > So, now I have two questions:<br>
> ><br>
> > 1. Imagine that I need to print something after all the nodes have been<br>
> matched.<br>
> > For example, the number of nodes matched. How can I do that?<br>
><br>
</div><div class="im">> You can just count how many times your match callback is called and then print<br>
> that number after run() returns.<br>
><br>
</div><div class="im">> > 2. Imagine that I have two methods within the run method to separate<br>
> > two kind of nodes I want to bind. Something like this:<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > class LoopPrinter : public MatchFinder::MatchCallback {public : virtual void<br>
> > run(const MatchFinder::MatchResult &Result) { applyMatch1();<br>
> > applyMatch2(); }<br>
> ><br>
> > void applyMatch1(){<br>
> > if (const ForStmt *FS =<br>
> > Result.Nodes.getNodeAs<clang::ForStmt>("forLoop__1"))<br>
> > }<br>
> ><br>
> > void apply2(){<br>
> > if (const ForStmt *FS =<br>
> > Result.Nodes.getNodeAs<clang::ForStmt>("forLoop_2"))<br>
> > }<br>
> > };<br>
><br>
</div><div class="im">> I'm not sure what order you're interested in but you can create two match<br>
> callbacks one to use for each matcher. The callbacks will be called in the order<br>
> the nodes are found in the tree by doing a depth-first pre-order traversal as is<br>
> usual for RecursiveASTVisitor. If both matchers match a given node, the<br>
> callbacks are called in the order they are registered.<br>
><br>
> What sort of order are you looking for?<br>
<br>
</div>Sorry, missed the comment in one of your more recent emails. So you basically want all matches by matcher1 to be found before all matchers by matcher2. I think the easiest way to do this is just have two MatchFinder classes. Add matcher1 and its callback to the first MatchFinder and call run(). Add matcher2 and its callback to the second MatchFinder and call run() after the first run() returns. You won't have to reparse the file but you will have to traverse the AST twice. There's not much you can do about this given the order you want. However, if the second matcher has no deps on the information collected by matcher1 you could just get away with a single MatchFinder and two callbacks that just store their finds in two vectors which you process after run returns.<br>
</blockquote><div><br></div><div style>What is often faster is to produce a superset of the information needed during the traversal / match phase, and then combine / filter the results after everything's done...</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
><br>
> ><br>
> ><br>
> ><br>
> > How does the 'run' method behave in this case? I mean that I don't<br>
> > know if it retrieves, one by one, all the nodes in applyMatch1 and<br>
> > ,after that, all the nodes in applyMatch2 or it matches one in<br>
> > applyMatch1 and then other in applyMatch2 in each iteration. I hope<br>
> > you can understand me because this is very important in my case.<br>
> ><br>
> > Thanks in advance.<br>
> ><br>
> > Pedro<br>
> ><br>
> ><br>
> ><br>
> > El dia 06 may 2013 22:32, "Vane, Edwin" <<a href="mailto:edwin.vane@intel.com">edwin.vane@intel.com</a>> escribió:<br>
> ><br>
> > Given your description, I'm not sure matchers are what you want. If<br>
> > you just want to print information on certain types of nodes, you<br>
> > could use a RecursiveASTVisitor for that.<br>
> ><br>
> > However, if what you're looking for is a little more complex then<br>
> > matchers may be what you want after all.<br>
> ><br>
> > As for the two classes, you want to use tooling::MatchFinder as shown<br>
> > in the tutorial. The other is just an implementation detail of the<br>
> > match finding code.<br>
> ><br>
> > newASTConsumer() is a function that's required to be defined for<br>
> > objects passed to newFrontendActionFactory(). You don't need to implement<br>
> it.<br>
> > It's implemented by MatchFinder. Again, it's an implementation detail<br>
> > you don't need to worry about at this point.<br>
> ><br>
> > The use of ASTConsumers is not necessary if you're using MatchFinder<br>
> > and ClangTool as described in the tutorial. MatchFinder is an<br>
> > abstraction around RecursiveASTVisitor so all that stuff in<br>
> > RecursiveASTVisitor you'd normally have to use is actually hidden away.<br>
> ><br>
> > I think you should first decide which route you want to go:<br>
> > MatchFinder or RecursiveASTVisitor. The first question I'd ask is: how<br>
> > hard is it to find the nodes I want to print info on in the AST. If all I want is<br>
> every for loop that's easy.<br>
> > If I want for loops within member functions of a specific class,<br>
> > that's hard and an excellent use case for ASTMatchers.<br>
> ><br>
> > -----Original Message-----<br>
> > From: <a href="mailto:cfe-dev-bounces@cs.uiuc.edu">cfe-dev-bounces@cs.uiuc.edu</a> [mailto:<a href="mailto:cfe-dev-">cfe-dev-</a><br>
> > <a href="mailto:bounces@cs.uiuc.edu">bounces@cs.uiuc.edu</a>] On<br>
> > Behalf Of Pedro Delgado Perez<br>
> > Sent: Monday, May 06, 2013 12:58 PM<br>
> > To: <a href="mailto:klimek@google.com">klimek@google.com</a>; <a href="mailto:kozargabor@gmail.com">kozargabor@gmail.com</a><br>
> > Cc: <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
> > Subject: Re: [cfe-dev] ASTMatchers: isVirtual and isOverride<br>
> ><br>
> > Hi,<br>
> ><br>
> > I need your help again. Look, in my tool I was trying to use the<br>
> > syntax that's<br>
> > shown here:<br>
> ><br>
> > <a href="http://clang.llvm.org/docs/LibASTMatchersTutorial.html" target="_blank">http://clang.llvm.org/docs/LibASTMatchersTutorial.html</a><br>
> ><br>
> > Namely I'm referring to this part:<br>
> ><br>
> > int main(int argc, const char **argv) {<br>
> > CommonOptionsParser OptionsParser(argc, argv);<br>
> > ClangTool Tool(OptionsParser.getCompilations(),<br>
> > OptionsParser.getSourcePathList());<br>
> ><br>
> > LoopPrinter Printer;<br>
> > MatchFinder Finder;<br>
> > Finder.addMatcher(LoopMatcher, &Printer);<br>
> ><br>
> > return Tool.run(newFrontendActionFactory(&Finder));<br>
> > }<br>
> ><br>
> > However, now I want to create a object "Printer" with different<br>
> > features<br>
> > depending on the arguments provided in command line. So I<br>
> was<br>
> > thinking on<br>
> > implement a factory method pattern to create a different<br>
> LoopPrinter<br>
> > object:<br>
> > class OptionsFactory {<br>
> > public:<br>
> > LoopPrinter getOption() {<br>
> > if(...)<br>
> > return LoopPrinter(attribute1, attribute2);<br>
> > else<br>
> > return LoopPrinter(attribute1);<br>
> > }<br>
> > };<br>
> ><br>
> > I was searching for a better solution and there are some things<br>
> that<br>
> > I can't<br>
> > completely understand.<br>
> ><br>
> > - Why are there two classes MatchFinder:<br>
> ><br>
</div></div><div class="im HOEnZb">> > <a href="http://clang.llvm.org/doxygen/classclang_1_1tooling_1_1MatchFinder" target="_blank">http://clang.llvm.org/doxygen/classclang_1_1tooling_1_1MatchFinder</a>.<br>
> > html<br>
> ><br>
> > <a href="http://clang.llvm.org/doxygen/classclang_1_1ast__matchers_1_1Matc" target="_blank">http://clang.llvm.org/doxygen/classclang_1_1ast__matchers_1_1Matc</a><br>
> > hFinder.<br>
</div><div class="HOEnZb"><div class="h5">> > html<br>
> ><br>
> > - What the method in ast_matchers:MatchFinder<br>
> ><br>
> > clang::ASTConsumer<br>
> ><br>
> > <<a href="http://clang.llvm.org/doxygen/classclang_1_1ASTConsumer.html" target="_blank">http://clang.llvm.org/doxygen/classclang_1_1ASTConsumer.html</a>> *<br>
> ><br>
> > newASTConsumer<br>
> ><br>
> > <<a href="http://clang.llvm.org/doxygen/classclang_1_1ast__matchers_1_1Mat" target="_blank">http://clang.llvm.org/doxygen/classclang_1_1ast__matchers_1_1Mat</a><br>
> > chFinder<br>
> > .html#a4807049e6e39572d19ff127406df3d81> ()<br>
> ><br>
> > is used for? I see we can 'associate' an ASTConsumer to the<br>
> Frontend<br>
> > as in:<br>
> > <a href="http://clang.llvm.org/docs/RAVFrontendAction.html" target="_blank">http://clang.llvm.org/docs/RAVFrontendAction.html</a><br>
> ><br>
> > but, is this possible using Matchers? Would it have any sense to<br>
> > create an<br>
> > ASTConsumer in my class OptionsFactory?<br>
> ><br>
> > I have improved a lot since you last helped me, but clang is too<br>
> > big!<br>
> ><br>
> > By the way, do you know how to use CommandLine? I posted a<br>
> new<br>
> > thread<br>
> ><br>
> > <a href="http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-" target="_blank">http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-</a><br>
> > May/029473.html<br>
> ><br>
> > If you know how to solve that problem, please, let me know.<br>
> ><br>
> > Thanks in advance,<br>
> ><br>
> > Pedro.<br>
> ><br>
> ><br>
> > El dia 27 abr 2013 18:39, Manuel Klimek <<a href="mailto:klimek@google.com">klimek@google.com</a>><br>
> > escribió:<br>
> ><br>
> > On Sat, Apr 27, 2013 at 6:36 PM, Gábor Kozár<br>
> > <<a href="mailto:kozargabor@gmail.com">kozargabor@gmail.com</a>> wrote:<br>
> ><br>
> ><br>
> ><br>
> > 2013/4/27 Manuel Klimek <<a href="mailto:klimek@google.com">klimek@google.com</a>><br>
> ><br>
> ><br>
> > Just use the empty string for binding and getNodeAs :)<br>
> ><br>
> ><br>
> > That would potentially lead to confusion when there are more<br>
> > nodes bound, but the programmer forgot to supply the proper<br>
> name. In<br>
> > my<br>
> > suggestion, the parameterless getNodeAs would have an assert<br>
> to<br>
> > check there is<br>
> > exactly one node bound (and whose name is the default name).<br>
> ><br>
> > If you put everything behind constants, I think it'll be easy<br>
> enough<br>
> > to see<br>
> > what's happening - and that's a generally good strategy<br>
> anyway, as<br>
> > you get a<br>
> > compile error if you mistype...<br>
> > Thus, I think it'd not add enough value to special case the<br>
> > interface.<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > 2013/4/27 Manuel Klimek <<a href="mailto:klimek@google.com">klimek@google.com</a>><br>
> ><br>
> ><br>
> > On Sat, Apr 27, 2013 at 6:28 PM, Gábor Kozár<br>
> > <<a href="mailto:kozargabor@gmail.com">kozargabor@gmail.com</a>> wrote:<br>
> ><br>
> > Hi,<br>
> > 2013/4/26 Pedro Delgado Perez<br>
> > <<a href="mailto:pedro.delgadoperez@mail.uca.es">pedro.delgadoperez@mail.uca.es</a>><br>
> ><br>
> ><br>
> > Hehehe... I found the problem with<br>
> > this. I was binding wrongly the matcher! I used a id in the<br>
> matcher<br>
> > thas was<br>
> > different from the id in the function that retrieves the nodes... I<br>
> > think this will be<br>
> > a typical mistake for newbies...<br>
> ><br>
> > Ah, yes, that happens a lot to me as well. Now<br>
> > that I think about it, it might be worthwhile adding a<br>
> parameterless<br>
> > .bind() and<br>
> > .getNodeAs<T>() for situations where only one node is bound.<br>
> > Should be fairly<br>
> > trivial, but also not all that useful...<br>
> ><br>
> > Just use the empty string for binding and getNodeAs :)<br>
> ><br>
> ><br>
> ><br>
> > 2013/4/26 Pedro Delgado Perez<br>
> > <<a href="mailto:pedro.delgadoperez@mail.uca.es">pedro.delgadoperez@mail.uca.es</a>><br>
> ><br>
> ><br>
> > Thanks both! Now I can see all this<br>
> > much clearer and I have the enough knowledge to start out with<br>
> > clang.<br>
> ><br>
> ><br>
> > You're welcome. Good luck!<br>
> ><br>
> ><br>
> > 2013/4/25 Manuel Klimek <<a href="mailto:klimek@google.com">klimek@google.com</a>><br>
> ><br>
> ><br>
> > And btw thanks a lot for all the great user support you're giving<br>
> > here!<br>
> ><br>
> ><br>
> > Thank you, I'm happy to help. Clang is a great project!<br>
> ><br>
> > As soon as the university term is over, I'm also planning on<br>
> trying<br>
> > to<br>
> > contribute code-wise, mainly to the Static Analyzer but I guess<br>
> also<br>
> > on just about<br>
> > anything that catches my attention. :) I'm quite excited - this is<br>
> > going to be the<br>
> > first open source project I contribute to.<br>
> > Gabor<br>
<br>
</div></div></blockquote></div><br></div></div>