[cfe-dev] RFC: What does this matcher mean to you?

[Daniel Jasper]

On Thu, Jun 6, 2013 at 4:58 PM, Manuel Klimek <klimek at google.com> wrote:

> On Thu, Jun 6, 2013 at 4:47 PM, Daniel Jasper <djasper at google.com> wrote:
>
>> I don't understand the confusion. To me, it feels kind of natural now.
>>
>> Consider a matcher similar to what we have looked at above:
>>
>> functionDecl(forEachDescendant(callExpr(callee(functionDecl().bind("f")))),
>> hasName("SomeFunction"));
>>
>> 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:
>>
>> functionDecl(forEachDescendant(callExpr(callee(functionDecl().bind("f")))),
>> equalsBoundNode("f"));
>>
>> 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.
>>
>> Or am I missing something?
>>
>
> Yes, there's a huge difference. (I agree with the proposed behavior tho)
> (1) is fixed with SomeFunction - that is, either all results from
> forEachDescendant apply, or none
> (2) means that the result set created by forEachDescendant is filtered
> down by equalsBoundNode
>

To me that seems to be an implementation difference, not a behavior
difference.


>
>>
>>
>>
>>
>>
>> On Thu, Jun 6, 2013 at 3:26 PM, Manuel Klimek <klimek at google.com> wrote:
>>
>>> On Thu, Jun 6, 2013 at 3:19 PM, Vane, Edwin <edwin.vane at intel.com>wrote:
>>>
>>>>
>>>>
>>>> > -----Original Message-----
>>>> > From: Manuel Klimek [mailto:klimek at google.com]
>>>> > Sent: Wednesday, June 05, 2013 12:24 PM
>>>> > To: Vane, Edwin
>>>> > Cc: Daniel Jasper; Gábor Kozár; Clang Dev List (cfe-dev at cs.uiuc.edu)
>>>> > Subject: Re: [cfe-dev] RFC: What does this matcher mean to you?
>>>>
>>>  >
>>>> > On Wed, Jun 5, 2013 at 5:53 PM, Vane, Edwin <edwin.vane at intel.com>
>>>> wrote:
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >       > -----Original Message-----
>>>> >       > From: Daniel Jasper [mailto:djasper at google.com]
>>>> >       > Sent: Tuesday, June 04, 2013 5:22 AM
>>>> >       > To: Vane, Edwin
>>>> >       > Cc: Manuel Klimek; Gábor Kozár; Clang Dev List (
>>>> cfe-dev at cs.uiuc.edu)
>>>> >       > Subject: Re: [cfe-dev] RFC: What does this matcher mean to
>>>> you?
>>>> >       >
>>>> >
>>>> >       > I think this question is basically not about
>>>> equalsBoundNodes() at all.
>>>> >       >
>>>> >       > The questions that needs answering are:
>>>> >       > - What should stmt(forEachDescendant(varDecl().bind("var")),
>>>> >       > forEachDescendant(declRefExpr().bind("decl"))) do?
>>>> >       > - What should stmt(forEachDescendant(varDecl().bind("var")),
>>>> >       > has(declRefExpr().bind("decl"))) do?
>>>> >       >
>>>> >       > I think the first should call the callback for each pair
>>>> (VarDecl,
>>>> > DeclRefExpr)
>>>> >       > under each Stmt. And the second should call the callback once
>>>> for
>>>> > each VarDecl
>>>> >       > under a Stmt that has a DeclRefExpr-child.
>>>> >
>>>> >
>>>> >       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.
>>>> >
>>>> >
>>>> >
>>>> > I think with the proposed change to how we match, the equalsBoundNode
>>>> > would naturally fit in as filtering matcher...
>>>>
>>>> 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.
>>>>
>>>> So given we seem to agree on how Daniel's two matchers behave, how does
>>>> this help us with equalsBoundNode()?
>>>>
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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)
>>>
>>>
>>>>
>>>> --
>>>> Edwin Vane
>>>>   Software Developer
>>>>   Intel of Canada, Inc.
>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130606/0aebc614/attachment.html>