What I usually do is: in the callback, take the source location of the node, look at the file name, and do a regexp on the file to determine whether you want to examine the node or not.
Well, but imagine that you have a .cpp with the definition of the methods of 3 classes, for example, and you only want to match nodes of that 3 classes (definitions and declarations). Then, you know each class has its declaration in one/some of the header files included, but you don’t know a priori where they are (normally, each class has a .h file with the same name as the class, but this is not always this way, so regular expressions don’t fit this case). However, you may have some other header files with other classes that you don’t want to match. How can I manage this? I know this is maybe a “extreme” case, but I think it’s important to me. This is why I insist.
What you can do, as Manuel suggested, is to perform the check in the callback. The SourceManager classs has various methods that are available for you to figure out where exactly a given SourceLocation is, and we’ve already mentioned several of them. I suggest you read through the documentation to find out what’s the best way to do what you’re trying to do.
Um, maybe I could firstly look for the classes’ names in the main file and then look for the location of their declarations so I was able to know which of the header files interest to me. Or do you think this is a though job?
The functionDecl() matcher in itself will match any FunctionDecl nodes, regardless of whether it is a definition or only a declaration. In addition, there is a method called FunctionDecl :: isDefinition, which also gives you the FunctionDecl object that represents the definition belonging to the current declaration.
Now I think the simplest solution would be to create a matcher for this, that would allow you to express constraints on the actual definition of the function, and then you’d be able to modify your existing matcher expression to accommodate for this.
I can’t find FunctionDecl :: isDefinition, but isDefined or TagTypeLoc:: isDefinition (I suppose you refer to this latter) , but these methods don’t give you the object that represents the definition belonging to the current declaration, just tell you if they are defitions as well, am I right?
If you are sure that all declarations of the constructor will be visible where it is implemented, you can match for the non-trivial default constructor, and then go backwards to all the decls you see from that TU.
If this is not true in your case (which in this example shouldn’t happen, I think), you can always output:
a) for all destructors, all declarations / definitions
b) for all non-trivial destructors, the fact that they’re non-trivial
Then you merge this information in a post-processing step. Things like this are quite common, which is why we’ve put together a MapReduce pipeline to support that kind of operation at a large scale, but for smaller code bases you can do something with a simple text format
Sorry, but I can’t follow you here. I’m not able to understand your explanation.
El dia 24 abr 2013 11:14, Gábor Kozár email@example.com escribió: