[cfe-dev] automatic bind for topmost matcher
Gábor Horváth
xazax.hun at gmail.com
Tue Oct 23 02:28:38 PDT 2012
What about non-trivial unit tests? I think sooner or later there could be
test, where you have to bind a matcher that is not on the top,and than you
have to pass the name to the callback anyways.
On 23 October 2012 11:05, Philip Craig <philipjcraig at gmail.com> wrote:
> On Tue, Oct 23, 2012 at 7:04 PM, Manuel Klimek <klimek at google.com> wrote:
> > On Tue, Oct 23, 2012 at 11:00 AM, Philip Craig <philipjcraig at gmail.com>
> > wrote:
> >>
> >> On Tue, Oct 23, 2012 at 6:44 PM, Manuel Klimek <klimek at google.com>
> wrote:
> >> > On Tue, Oct 23, 2012 at 10:37 AM, Philip Craig <
> philipjcraig at gmail.com>
> >> > wrote:
> >> >>
> >> >> In a MatchCallback, is there any way of determining the topmost node
> >> >> that was matched without needing to bind it? This would merely be a
> >> >> convenience, similar to the way that regular expressions always
> return
> >> >> the complete match, and you only have to gives names to parts of the
> >> >> regular expression if you want the subexpressions.
> >> >
> >> >
> >> > Currently not, as you can always write .bind("x") very easily. What
> name
> >> > would you propose?
> >>
> >> My desire was to not need any name, so that I could just call
> >> Result.Nodes.getNodeAs<T>() without any argument.
> >>
> >> For the situation that prompted my question see
> >> http://llvm-reviews.chandlerc.com/D72. Always having access to the top
> >> node would avoid the need for the NodeVerifier class in that patch.
> >
> >
> > You'd still need a callback where you pull it out of the results,
> wouldn't
> > you?
>
> Yes, but I wouldn't need to tell the callback what name to use, and
> the callback wouldn't need to check whether a node with that name was
> bound, because the topmost node would always be bound.
> _______________________________________________
> 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/20121023/629b63f0/attachment.html>
More information about the cfe-dev
mailing list