[cfe-dev] automatic bind for topmost matcher

Philip Craig philipjcraig at gmail.com
Tue Oct 23 04:02:53 PDT 2012


On Tue, Oct 23, 2012 at 7:25 PM, Manuel Klimek <klimek at google.com> wrote:
> On Tue, Oct 23, 2012 at 11:05 AM, 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.
>
>
> If you don't do the bind into the test code, but sink it into where you take
> the matcher (and make that the same class that does the verification,
> perhaps using an inner class), you can have the bind("id") call and the
> pulling out of the result into the same level of abstraction.

That looks like it should clean things up, thanks. I just need to
brush up on using member function templates first.

> Even with a default binding, you'd still need to check that the node is
> there, as the types might not match, right?

Yes you're right.

> That said, I don't have a big problem with adding .bind("") to all
> addMatcher calls in the ASTMatchFinder; I don't see how it would interfere
> with anything - patch welcome :)
>
> Cheers,
> /Manuel
>



More information about the cfe-dev mailing list