<div dir="ltr">On Wed, Jun 5, 2013 at 5:53 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: Daniel Jasper [mailto:<a href="mailto:djasper@google.com">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">cfe-dev@cs.uiuc.edu</a>)<br>
> Subject: Re: [cfe-dev] RFC: What does this matcher mean to you?<br>
><br>
</div><div class="im">> 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, DeclRefExpr)<br>
> under each Stmt. And the second should call the callback once for each VarDecl<br>
> under a Stmt that has a DeclRefExpr-child.<br>
<br>
</div>I agree. This is in line with the current definition and behaviour of the involved matchers. I interpret the 'filtering' behaviour as something new that, if we want to implement it, needs a different matcher to expose. I think the equalsBoundNode() matcher is independent of the filtering behaviour.<br>
</blockquote><div><br></div><div style>I think with the proposed change to how we match, the equalsBoundNode would naturally fit in as filtering matcher...</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>
> The matchers themselves match, if the callback was invoked at least once.<br>
><br>
> I think we need to answer these questions first and then the behavior of<br>
> equalsBoundNodes() will follow naturally.<br>
><br>
><br>
> On Thu, May 23, 2013 at 3:01 PM, Vane, Edwin <<a href="mailto:edwin.vane@intel.com">edwin.vane@intel.com</a>> wrote:<br>
><br>
><br>
>       To help stimulate discussion, let me present the two ways this matcher<br>
> has been interpreted:<br>
><br>
>       1) An "all or nothing" matcher. equalsBoundNode("X") returns true if<br>
> there exists any previously bound node called "X" and that node satisfies an<br>
> identity relationship with the node passed to equalsBoundNode. If no such node<br>
> exists, the matcher just returns false and the match fails, much like any other<br>
> matcher.<br>
>       2) As a filter. Consider the matches found by forEach*() as the set of<br>
> matches. Then the has() matcher containing equalsBoundNode() is used as a<br>
> filter over this set. Whenever equalsBoundNode() locates a previously bound<br>
> node with the correct name and satisfying the identity condition, it's really<br>
> referring to a node in the match set. If the has() matcher fails, the node gets<br>
> removed from the match set.<br>
><br>
>       The difference can be seen by looking at what matches get returned<br>
> from either interpretation. With #1, as long as a functionDecl has at least one<br>
> call statement to a function returning a type that matches any of the varDecls<br>
> found within ifStmt's, the function will match and the set of bound nodes will be<br>
> *every* varDecl found within ifStmts.<br>
><br>
>       With #2, the matcher will match (When? Same as #1? Only if the set of<br>
> bound nodes is non-empty?) and the set of bound nodes will be only those<br>
> varDecls whose type matches the return type of a function called somewhere in<br>
> the function.<br>
><br>
>       I have my thoughts on both but don't want to influence anybody before<br>
> hearing opinions first.<br>
><br>
><br>
>       > -----Original Message-----<br>
>       > From: Manuel Klimek [mailto:<a href="mailto:klimek@google.com">klimek@google.com</a>]<br>
>       > Sent: Thursday, May 23, 2013 5:42 AM<br>
>       > To: Gábor Kozár<br>
>       > Cc: Vane, Edwin; Clang Dev List (<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a>)<br>
>       > Subject: Re: [cfe-dev] RFC: What does this matcher mean to you?<br>
>       ><br>
><br>
>       > For clarification: the problem is less "whether it matches", but for<br>
> which<br>
>       > matches you get callbacks with what bound nodes.<br>
>       ><br>
>       > The forEachDescendant(... .bind("declType")) part in the matcher on<br>
> its own will<br>
>       > result in a callback for each found declType child, with the node bound<br>
> to<br>
>       > "declType".<br>
>       ><br>
>       > The question is: given that there are multiple matches for<br>
> forEachDescendant,<br>
>       > what is the behavior of the has(... equalsBoundNode("declType"))<br>
> part:<br>
>       > How many callbacks with which bound nodes do you expect?<br>
>       ><br>
>       > Cheers,<br>
>       > /Manuel<br>
>       ><br>
>       ><br>
>       ><br>
>       > On Tue, May 21, 2013 at 7:35 PM, Gábor Kozár<br>
> <<a href="mailto:kozargabor@gmail.com">kozargabor@gmail.com</a>><br>
>       > wrote:<br>
>       ><br>
>       ><br>
>       >       I would expect it the equalsBoundNode("declType") to either:<br>
>       ><br>
>       >        - raise an error (assertion failure or exception) or<br>
>       >        - check all nodes bound to "declType", and return true if any of<br>
> them is<br>
>       > equal<br>
>       ><br>
>       >       Perhaps different variants could be introduced with both<br>
> behaviors? For<br>
>       > example, equalsBoundNode(string) would only work if there is exactly<br>
> one node<br>
>       > bound to the specified name, while equalsAnyBoundNode(string)<br>
> would look for<br>
>       > equality in any node bound to the specified name.<br>
>       ><br>
>       ><br>
>       >       2013/5/21 Vane, Edwin <<a href="mailto:edwin.vane@intel.com">edwin.vane@intel.com</a>><br>
>       ><br>
>       ><br>
>       >               We're trying to determine the semantics of the proposed new<br>
>       > 'equalsBoundNode()' matcher. Before I present the aforementioned<br>
> matcher<br>
>       > expression let me illustrate what this new matcher does. Given that<br>
> you've<br>
>       > bound a node earlier in a matcher expression with a name "X",<br>
>       > equalsBoundNode("X") allows you to refer back to that bound node<br>
> and test for<br>
>       > identity. For example, here's a matcher finding VarDecl's where the<br>
> type<br>
>       > matches the initializer type:<br>
>       ><br>
>       >               varDecl(hasType(qualType().bind("type")),<br>
>       ><br>
>       ><br>
> hasInitializer(ignoringParenImpCasts(hasType(qualType(equalsBoundNode("type<br>
>       > "))))))));<br>
>       ><br>
>       >               Semantics get more interesting where forEach*() matchers are<br>
>       > concerned. So this is where I ask: What would you expect the<br>
> following matcher<br>
>       > to do? How would you expect it to behave?<br>
>       ><br>
>       >                   functionDecl(<br>
>       >                     forEachDescendant(<br>
>       >                       ifStmt(<br>
>       >                         forEachDescendant(<br>
>       >                           varDecl(hasType(qualType().bind("declType")))<br>
>       >                         )<br>
>       >                       )<br>
>       >                     ),<br>
>       >                     has(compoundStmt(has(<br>
>       >                       callExpr(<br>
>       >                         callee(<br>
>       >                           functionDecl(<br>
>       >                             returns(qualType(equalsBoundNode("declType")))<br>
>       >                           )<br>
>       >                         )<br>
>       >                       )<br>
>       >                     )))<br>
>       >                   );<br>
>       ><br>
>       ><br>
>       >               --<br>
>       >               Edwin Vane<br>
>       >                 Software Developer<br>
>       >                 Intel of Canada, Inc.<br>
>       ><br>
>       ><br>
>       >               _______________________________________________<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>
>       ><br>
>       ><br>
>       ><br>
>       ><br>
>       >       _______________________________________________<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>
>       ><br>
>       ><br>
>       ><br>
><br>
><br>
>       _______________________________________________<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>
><br>
><br>
<br>
</div></div></blockquote></div><br></div></div>