Getting the Bindings of MatchFinder::MatchResult

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.

Would like to hear some thoughts on the idea and possible solutions.

This is my Code sofar:

namespace {
class ReportingCallback : public MatchFinder::MatchCallback {
public:
    ReportingCallback(){}
  virtual void run(const MatchFinder::MatchResult &Result)
    {
        str.str("");//reset
        const Stmt* stmt = Result.Nodes.getStmtAs<Stmt>("id");
        const Decl* decl = Result.Nodes.getDeclAs<Decl>("id");
       
        str << "Found Match in " << Result.SourceManager->getFilename(Result.SourceManager->?);
        matches.push_back(str.str());
  }
private:
    std::vector<std::string> matches;
    std::stringstream str;
};
} // end anonymous namespace

kind regards,

Jens Weller

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.

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.

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.

Cheers,
/Manuel

> 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