<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Mar 13, 2014 at 11:32 PM, Richard <span dir="ltr"><<a href="mailto:legalize@xmission.com" target="_blank">legalize@xmission.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
My apologies to Stephen for not noticing that he was already doing<br>
what I was suggesting (starting with remove-cstr-calls and modifying).<br>
<div class=""><br>
In article <lfmm58$e8i$<a href="mailto:1@ger.gmane.org">1@ger.gmane.org</a>>,<br>
Stephen Kelly <<a href="mailto:steveire@gmail.com">steveire@gmail.com</a>> writes:<br>
<br>
</div><div class="">> From the -ast-dump, it looks like I need to first match a<br>
> CXXOperatorCallExpr, so I write this matcher:<br>
><br>
> Finder.addMatcher(<br>
> id("match", operatorCallExpr()),<br>
> &Callback);<br>
><br>
> which gives me lots of output, mostly from the iostream header. I need to<br>
> get narrower.<br>
<br>
</div>In my "remove-void-arg" example, I did an extra check to see if<br>
something was declared extern "C", because we don't want to change<br>
<br>
extern "C" {<br>
int foo(void);<br>
}<br>
<br>
into<br>
<br>
extern "C" {<br>
int foo();<br>
}<br>
<br>
I'm pretty sure I'd run into the same problem as Stephen once my test<br>
inputs were broadened from simple cases to real-world code.<br>
<br>
I think this is a general problem -- namely that when you include header<br>
files, either from the standard library or third party libraries, your<br>
refactoring tool can match all kinds of code that is in their headers.<br>
<br>
The Visual Assist X add-on for Visual Studio has a way of specifying a<br>
directory hierarchy of "stable" includes that it ignores for various<br>
operations, including refactoring operations. By default, it puts all<br>
the Visual Studio headers in this stable list.<br>
<br>
I was thinking that a simple filter would be to look at the file<br>
associated with the source location of the match and if that file<br>
isn't one of the translation units mentioned in the compilation<br>
database, then we would discount the match. This works well for .cpp<br>
files, but obviously misses header files.<br>
<br>
It sounds like it would be useful to have an AST matcher that provided<br>
this sort of filtering so you could just include it as an additional<br>
predicate in your matcher and not have to repeat the work of filtering<br>
out "uninteresting" source locations.<br>
<br>
I looked on the matchers page and didn't seem to see any matchers that<br>
filter based on the file origin of a node in the AST.<br></blockquote><div><br></div><div>We usually create all changes and filter either in the match callback (return early if the source location is in an uninteresting file), or after-the-fact.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=""><br>
> In the -ast-dump output there is a CXXMemberCallExpr nested in the<br>
> CXXOperatorCallExpr. I make a logical jump at matching that:<br>
><br>
> Finder.addMatcher(<br>
> id("match", operatorCallExpr(memberCallExpr())),<br>
> &Callback);<br>
><br>
> However, that produces no output, so my logical jump must be incorrect.<br>
<br>
</div>I think the reason you didn't get a match here is that the structure is:<br>
<br>
CXXOperatorCallExpr<br>
|-ImplicitCastExpr<br>
|-DeclRefExpr<br>
|-CXXOperatorCallExpr<br>
| |-CXXMemberCallExpr<br>
<br>
<<a href="http://clang.llvm.org/docs/LibASTMatchersReference.html" target="_blank">http://clang.llvm.org/docs/LibASTMatchersReference.html</a>> says that<br>
operatorCallExpr expects a Matcher<CXXOperatorCallExpr> argument, but<br>
you supplied memberCallExpr() which returns type Matcher<Stmt>.<br>
<br>
operatorCallExpr() could take hasOverloadedOperatorName() in order to<br>
narrow it to the specific operator.<br>
<br>
I think then you need to narrow it further based on the arguments to<br>
the operator.<br>
<br>
I would have to verify this hypothesis by reproducing your experiment,<br>
but perhaps another list reader with more experience can confirm my<br>
hypothesis.<br>
<div class=""><br>
> How does one go about *actually* writing matcher code?<br>
<br>
</div>I did something similar to what you did, but I think this process<br>
still has some bumps in the road and could be made easier still.<br>
<br>
The first bump I'm trying to help iron out is that the pre-built<br>
packages don't have everything you need to build refactoring tools.<br>
<br>
(aside: this made me laugh:<br>
StringLiteral 0x275cc88 <col:17> 'const char [4]' lvalue "wtf")<br>
<div class="im HOEnZb">--<br>
"The Direct3D Graphics Pipeline" free book <<a href="http://tinyurl.com/d3d-pipeline" target="_blank">http://tinyurl.com/d3d-pipeline</a>><br>
The Computer Graphics Museum <<a href="http://ComputerGraphicsMuseum.org" target="_blank">http://ComputerGraphicsMuseum.org</a>><br>
The Terminals Wiki <<a href="http://terminals.classiccmp.org" target="_blank">http://terminals.classiccmp.org</a>><br>
Legalize Adulthood! (my blog) <<a href="http://LegalizeAdulthood.wordpress.com" target="_blank">http://LegalizeAdulthood.wordpress.com</a>><br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div></div>