[cfe-dev] Getting the Bindings of MatchFinder::MatchResult

[Jens Weller]

> On Fri, Aug 17, 2012 at 12:02 PM, Jens Weller <JensWeller at gmx.de> wrote:
> > Hi,
> >
> > wasn't sure how to name this one, I have a nice idea:
> > Building a Counting/Stats/Reporting Callback for ast_matchers.
> >
> > Background: I think this would be kind of useful, beeing able to run
> matchers against a class that can report what places in code are found.
> Without changing them.
> > This gives me as a Tool Author the option of displaying to the user,
> where changes will be made to the code, or maybe even what changes.
> >
> > I thought this is an easy one, and once I'm done, I'll post it to the
> list.
> > Well, counting is easy. But actually I want to know, where are those
> changes, which Files are affected. So, I'd like to have an vector<string> to
> record all found places.
> >
> > Now, as this Reporting Callback runs against matchers it does not know,
> and as far as I've understood, the Bindings of BoundNodes are userdefined
> strings. Which aren't exposed to me. I can query them, but actually I'd need
> in this case either access to them, or, maybe even better, some exposed
> information, maybe SourceLocation start,end would be already enough. I'd like
> to be able to report things like File, FileLocation (line, column) etc.
> 
> Well, you can for example hand the id's into the callback class via
> the constructor.

Well, I thought about this one, and came to the conclusion, that a getter for the bindings BoundNodes would be the best solution.

> > Would like to hear some thoughts on the idea and possible solutions.
> 
> I think in principle this is a nice idea, but currently I don't see a
> strong need for putting that level of abstraction into a central place
> - I'd like to see some more evidence that this is widely used.

Well, right now I think all that is needed to make such thing possible is adding 2 getters to BoundNodes, which return the corresponding bindings.

> For exploratory use cases I'd be more interested in seeing a dynamic
> approach with a tool that can parse a matcher expression and then give
> you all the locations where it matches.

Yeah, I think so too. A list of sourcepositions or so would be the best way to go.

kind regards,

Jens Weller