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

[Manuel Klimek]

On Thu, Jun 6, 2013 at 5:12 PM, Daniel Jasper <djasper at google.com> wrote:

>
>
>
> 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.
>

Well, it definitely restricts the set of possible implementations...


>
>
>>
>>>
>>>
>>>
>>>
>>>
>>> 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/0773ae13/attachment.html>