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

Daniel Jasper djasper at google.com
Tue Jun 4 02:22:25 PDT 2013


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.

The matchers themselves match, if the callback was invoked at least once.

I think we need to answer these questions first and then the behavior of
equalsBoundNodes() will follow naturally.


On Thu, May 23, 2013 at 3:01 PM, Vane, Edwin <edwin.vane at intel.com> wrote:

> To help stimulate discussion, let me present the two ways this matcher has
> been interpreted:
>
> 1) An "all or nothing" matcher. equalsBoundNode("X") returns true if there
> exists any previously bound node called "X" and that node satisfies an
> identity relationship with the node passed to equalsBoundNode. If no such
> node exists, the matcher just returns false and the match fails, much like
> any other matcher.
> 2) As a filter. Consider the matches found by forEach*() as the set of
> matches. Then the has() matcher containing equalsBoundNode() is used as a
> filter over this set. Whenever equalsBoundNode() locates a previously bound
> node with the correct name and satisfying the identity condition, it's
> really referring to a node in the match set. If the has() matcher fails,
> the node gets removed from the match set.
>
> The difference can be seen by looking at what matches get returned from
> either interpretation. With #1, as long as a functionDecl has at least one
> call statement to a function returning a type that matches any of the
> varDecls found within ifStmt's, the function will match and the set of
> bound nodes will be *every* varDecl found within ifStmts.
>
> With #2, the matcher will match (When? Same as #1? Only if the set of
> bound nodes is non-empty?) and the set of bound nodes will be only those
> varDecls whose type matches the return type of a function called somewhere
> in the function.
>
> I have my thoughts on both but don't want to influence anybody before
> hearing opinions first.
>
> > -----Original Message-----
> > From: Manuel Klimek [mailto:klimek at google.com]
> > Sent: Thursday, May 23, 2013 5:42 AM
> > To: Gábor Kozár
> > Cc: Vane, Edwin; Clang Dev List (cfe-dev at cs.uiuc.edu)
> > Subject: Re: [cfe-dev] RFC: What does this matcher mean to you?
> >
> > For clarification: the problem is less "whether it matches", but for
> which
> > matches you get callbacks with what bound nodes.
> >
> > The forEachDescendant(... .bind("declType")) part in the matcher on its
> own will
> > result in a callback for each found declType child, with the node bound
> to
> > "declType".
> >
> > The question is: given that there are multiple matches for
> forEachDescendant,
> > what is the behavior of the has(... equalsBoundNode("declType")) part:
> > How many callbacks with which bound nodes do you expect?
> >
> > Cheers,
> > /Manuel
> >
> >
> >
> > On Tue, May 21, 2013 at 7:35 PM, Gábor Kozár <kozargabor at gmail.com>
> > wrote:
> >
> >
> >       I would expect it the equalsBoundNode("declType") to either:
> >
> >        - raise an error (assertion failure or exception) or
> >        - check all nodes bound to "declType", and return true if any of
> them is
> > equal
> >
> >       Perhaps different variants could be introduced with both
> behaviors? For
> > example, equalsBoundNode(string) would only work if there is exactly one
> node
> > bound to the specified name, while equalsAnyBoundNode(string) would look
> for
> > equality in any node bound to the specified name.
> >
> >
> >       2013/5/21 Vane, Edwin <edwin.vane at intel.com>
> >
> >
> >               We're trying to determine the semantics of the proposed new
> > 'equalsBoundNode()' matcher. Before I present the aforementioned matcher
> > expression let me illustrate what this new matcher does. Given that
> you've
> > bound a node earlier in a matcher expression with a name "X",
> > equalsBoundNode("X") allows you to refer back to that bound node and
> test for
> > identity. For example, here's a matcher finding VarDecl's where the type
> > matches the initializer type:
> >
> >               varDecl(hasType(qualType().bind("type")),
> >
> >
> hasInitializer(ignoringParenImpCasts(hasType(qualType(equalsBoundNode("type
> > "))))))));
> >
> >               Semantics get more interesting where forEach*() matchers
> are
> > concerned. So this is where I ask: What would you expect the following
> matcher
> > to do? How would you expect it to behave?
> >
> >                   functionDecl(
> >                     forEachDescendant(
> >                       ifStmt(
> >                         forEachDescendant(
> >                           varDecl(hasType(qualType().bind("declType")))
> >                         )
> >                       )
> >                     ),
> >                     has(compoundStmt(has(
> >                       callExpr(
> >                         callee(
> >                           functionDecl(
> >
> returns(qualType(equalsBoundNode("declType")))
> >                           )
> >                         )
> >                       )
> >                     )))
> >                   );
> >
> >
> >               --
> >               Edwin Vane
> >                 Software Developer
> >                 Intel of Canada, Inc.
> >
> >
> >               _______________________________________________
> >               cfe-dev mailing list
> >               cfe-dev at cs.uiuc.edu
> >               http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >
> >
> >
> >
> >       _______________________________________________
> >       cfe-dev mailing list
> >       cfe-dev at cs.uiuc.edu
> >       http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >
> >
> >
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130604/c09727a1/attachment.html>


More information about the cfe-dev mailing list