<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 6, 2013 at 4:58 PM, Manuel Klimek <span dir="ltr"><<a href="mailto:klimek@google.com" target="_blank" class="cremed">klimek@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="im">On Thu, Jun 6, 2013 at 4:47 PM, Daniel Jasper <span dir="ltr"><<a href="mailto:djasper@google.com" target="_blank" class="cremed">djasper@google.com</a>></span> wrote:<br>
</div><div class="gmail_extra"><div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I don't understand the confusion. To me, it feels kind of natural now.<div><br></div><div>Consider a matcher similar to what we have looked at above:</div>
<div><br></div><div><font face="arial, sans-serif">functionDecl(forEachDescendant(callExpr(callee(functionDecl().bind("f")))), hasName("SomeFunction"));</font></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">This is very similar to my second example case. The callback will be called once for each CallExpr in the function "SomeFunction" with the called function bound to "f". Now, if we change this to:</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><div><font face="arial, sans-serif">functionDecl(forEachDescendant(callExpr(callee(functionDecl().bind("f")))), equalsBoundNode("f"))</font><span style="font-family:arial,sans-serif">;</span></div>
<div><span style="font-family:arial,sans-serif"><br></span></div><div><font face="arial, sans-serif">This equalsBoundNode matcher will behave exactly like the hasName()-matcher. Thus, the callback will be called once for each CallExpr where a function calls itself recursively.</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Or am I missing something?</font></div></div></div></blockquote><div><br></div></div><div>Yes, there's a huge difference. (I agree with the proposed behavior tho)</div>
<div>(1) is fixed with SomeFunction - that is, either all results from forEachDescendant apply, or none</div><div>(2) means that the result set created by forEachDescendant is filtered down by equalsBoundNode</div></div>
</div></div></blockquote><div><br></div><div style>To me that seems to be an implementation difference, not a behavior difference.</div><div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><font face="arial, sans-serif"><br></font></div></div><div>
<div><br></div><div><br></div></div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 6, 2013 at 3:26 PM, Manuel Klimek <span dir="ltr"><<a href="mailto:klimek@google.com" target="_blank" class="cremed">klimek@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>On Thu, Jun 6, 2013 at 3:19 PM, Vane, Edwin <span dir="ltr"><<a href="mailto:edwin.vane@intel.com" target="_blank" class="cremed">edwin.vane@intel.com</a>></span> wrote:<br>
</div></div><div class="gmail_extra"><div class="gmail_quote"><div><div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br>
<br>
> -----Original Message-----<br>
> From: Manuel Klimek [mailto:<a href="mailto:klimek@google.com" target="_blank" class="cremed">klimek@google.com</a>]<br>
</div><div>> Sent: Wednesday, June 05, 2013 12:24 PM<br>
> To: Vane, Edwin<br>
</div><div><div>> Cc: Daniel Jasper; Gábor Kozár; Clang Dev List (<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank" class="cremed">cfe-dev@cs.uiuc.edu</a>)<br>
> Subject: Re: [cfe-dev] RFC: What does this matcher mean to you?<span style="color:rgb(34,34,34)"> </span></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div>
><br>
> On Wed, Jun 5, 2013 at 5:53 PM, Vane, Edwin <<a href="mailto:edwin.vane@intel.com" target="_blank" class="cremed">edwin.vane@intel.com</a>> wrote:<br>
><br>
><br>
><br>
><br>
> > -----Original Message-----<br>
> > From: Daniel Jasper [mailto:<a href="mailto:djasper@google.com" target="_blank" class="cremed">djasper@google.com</a>]<br>
> > Sent: Tuesday, June 04, 2013 5:22 AM<br>
> > To: Vane, Edwin<br>
> > Cc: Manuel Klimek; Gábor Kozár; Clang Dev List (<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank" class="cremed">cfe-dev@cs.uiuc.edu</a>)<br>
> > Subject: Re: [cfe-dev] RFC: What does this matcher mean to you?<br>
> ><br>
><br>
> > I think this question is basically not about equalsBoundNodes() at all.<br>
> ><br>
> > The questions that needs answering are:<br>
> > - What should stmt(forEachDescendant(varDecl().bind("var")),<br>
> > forEachDescendant(declRefExpr().bind("decl"))) do?<br>
> > - What should stmt(forEachDescendant(varDecl().bind("var")),<br>
> > has(declRefExpr().bind("decl"))) do?<br>
> ><br>
> > I think the first should call the callback for each pair (VarDecl,<br>
> DeclRefExpr)<br>
> > under each Stmt. And the second should call the callback once for<br>
> each VarDecl<br>
> > under a Stmt that has a DeclRefExpr-child.<br>
><br>
><br>
> I agree. This is in line with the current definition and behaviour of the<br>
> involved matchers. I interpret the 'filtering' behaviour as something new that, if<br>
> we want to implement it, needs a different matcher to expose. I think the<br>
> equalsBoundNode() matcher is independent of the filtering behaviour.<br>
><br>
><br>
><br>
> I think with the proposed change to how we match, the equalsBoundNode<br>
> would naturally fit in as filtering matcher...<br>
<br>
</div></div>What do you mean by proposed change to *how* we match? The equalsBoundNode() matcher was meant to be just another matcher. If we want to use it for filtering I still think we need a different matcher to expose that functionality. Otherwise we're changing the semantics of existing matchers.<br>
<br>
So given we seem to agree on how Daniel's two matchers behave, how does this help us with equalsBoundNode()?<br></blockquote><div><br></div></div></div><div>To me equalsBoundNode is not just another matcher - many details on how bound nodes are handled get exposed with equalsBoundNode, because the relevant information was not accessible at those points before.</div>
<div><br></div><div>For example, before equalsBoundNode, whether a matcher passed for failed did not depend on the set of bound nodes at that point - that's a very big change, for example, we need to take it into account when doing memoization, otherwise we'll create inconsistent results.</div>
<div><br></div><div>Also, I don't think that the proposed non-filtering behavior of equalsBoundNode is user friendly. I think that having it be a filtering matcher makes more sense, and that other filtering matchers are a different topic (as, in principle, all matchers are already filtering matchers on predicates of nodes, apart from the forEach matchers)</div>
<div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div><br>
--<br>
Edwin Vane<br>
Software Developer<br>
Intel of Canada, Inc.<br>
<br>
<br>
</div></div></blockquote></div></div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div></div>