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

[Manuel Klimek]

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