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

[Vane, Edwin]

> -----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()?

--
Edwin Vane
  Software Developer
  Intel of Canada, Inc.