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

[Daniel Jasper]

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?





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/772a269b/attachment.html>