<div dir="ltr">On Thu, Jun 6, 2013 at 3:19 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: Manuel Klimek [mailto:<a href="mailto:klimek@google.com">klimek@google.com</a>]<br>
</div><div class="im">> Sent: Wednesday, June 05, 2013 12:24 PM<br>
> To: Vane, Edwin<br>
</div><div><div class="h5">> Cc: Daniel Jasper; 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?<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 class="h5">
><br>
> On Wed, Jun 5, 2013 at 5:53 PM, Vane, Edwin <<a href="mailto:edwin.vane@intel.com">edwin.vane@intel.com</a>> wrote:<br>
><br>
><br>
><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>
><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 style>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 style><br></div><div style>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 style><br></div><div style>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><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>
Edwin Vane<br>
Software Developer<br>
Intel of Canada, Inc.<br>
<br>
<br>
</div></div></blockquote></div><br></div></div>