[cfe-dev] ASTMatchers: isVirtual and isOverride

[Pedro Delgado Perez]

Hi both,

> 
> Unfortunately, class declarations and class definitions (including method definitions) can be anywhere, regardless of whether that file is a header file or not (e.g. when templates are considered, or when a class is considered an implementation detail, etc.). Also unless you're working in a very anti-oop environment, I think it is a safe bet that all files will usually contain classes - or if not, then they are very small, and don't have a considerable impact on performance. So I think you can't do much better than filtering out only the system header files.
I agree with you. I think this is what I will do for the moment.

> I think what Manuel means - and which is a very good point by the way - is that it's possible that a class or method was declared multiple times, because C++ allows this. (Of course, it still needs to have at most one definition.) You can handle this by going through the declaration chain using FunctionDecl :: getPreviousDecl (http://clang.llvm.org/doxygen/classclang_1_1Redeclarable.html#ae865b5549d99099ecb62d8b3a104f033 [ http://clang.llvm.org/doxygen/classclang_1_1Redeclarable.html#ae865b5549d99099ecb62d8b3a104f033 ]).
> 
Wow! This is exactly what I needed! I tested this method and it worked as I was expecting. Thanks!

> Otherwise, in less well-behaving cases (which is usually what you want to be prepared for) you might need to perform the work in two steps: first, gather all constructor declarations (ideally some kind map, where the key is a constructor definition, and the value is a list of declarations belonging to that definition) that are potentially of interest to you, and in the second step iterate through the gathered declarations, and you should be able to make the final decision based on that collected data (since you'll have all definitions and declarations gathered).
> 
Ok, I catch the idea now. It's great, thanks for sharing it. I suppose that I will finally decide what to do in these cases when I really get down to work.  

> > Umm... What a strange thing... I will get over this one more time and see if I did something wrong.
> Maybe something is missing or is different in AStMatchersInternal or ASTMatchersMacros.
> Yes, that's quite possible, as I'm using clang 3.2. Nonetheless, you should be able to figure out what the issue is, as I've given you a draft (a pattern, if you will).
Hehehe... I found the problem with this. I was binding wrongly the matcher! I used a id in the matcher thas was different from the id in the function that retrieves the nodes... I think this will be a typical mistake for newbies... 

> Just FYI: yes, this is generally the process - I'd also highly appreciate using phabricator for those patches (http://llvm.org/docs/Phabricator.html [ http://llvm.org/docs/Phabricator.html ]) :)
> 
Ok. This is good to know it.

> And btw thanks a lot for all the great user support you're giving here!
> 
Thanks both! Now I can see all this much clearer and I have the enough knowledge to start out with clang.

> A last question to finish, if you don't mind. I save the changes I make in the code in a new file through fstream header , but I was wondering if Clang provides a way to create and save new files using some of its classes.
> 
Regards,

Pedro.

El dia 25 abr 2013 06:38, Manuel Klimek <klimek at google.com> escribió:
> On Thu, Apr 25, 2013 at 1:51 AM, Gábor Kozár <kozargabor at gmail.com [ mailto:kozargabor at gmail.com ]> wrote:
> 
> 
> 
> Hi,
> 
> 
> 
> > 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?
> 
> 
> Unfortunately, class declarations and class definitions (including method definitions) can be anywhere, regardless of whether that file is a header file or not (e.g. when templates are considered, or when a class is considered an implementation detail, etc.). Also unless you're working in a very anti-oop environment, I think it is a safe bet that all files will usually contain classes - or if not, then they are very small, and don't have a considerable impact on performance. So I think you can't do much better than filtering out only the system header files.
> 
> 
> > 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?
> 
> 
> Sorry, what I meant was FunctionDecl :: isDefined (http://clang.llvm.org/doxygen/classclang_1_1FunctionDecl.html#a4a68908ca34bfedaaf8b0a80d865f54f [ http://clang.llvm.org/doxygen/classclang_1_1FunctionDecl.html#a4a68908ca34bfedaaf8b0a80d865f54f ]).
> 
> 
> 
> > 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.
> 
> 
> I think what Manuel means - and which is a very good point by the way - is that it's possible that a class or method was declared multiple times, because C++ allows this. (Of course, it still needs to have at most one definition.) You can handle this by going through the declaration chain using FunctionDecl :: getPreviousDecl (http://clang.llvm.org/doxygen/classclang_1_1Redeclarable.html#ae865b5549d99099ecb62d8b3a104f033 [ http://clang.llvm.org/doxygen/classclang_1_1Redeclarable.html#ae865b5549d99099ecb62d8b3a104f033 ]).
> 
> Otherwise, in less well-behaving cases (which is usually what you want to be prepared for) you might need to perform the work in two steps: first, gather all constructor declarations (ideally some kind map, where the key is a constructor definition, and the value is a list of declarations belonging to that definition) that are potentially of interest to you, and in the second step iterate through the gathered declarations, and you should be able to make the final decision based on that collected data (since you'll have all definitions and declarations gathered).
That's pretty much what I meant (but was unable to explain well enough :), apart from that I'd also build up a map where the key is the constructor definition and the value is "is this interesting".
 

(Sorry for going over your head, Manuel!)
Never worry about that! :) My head is very small ...
And btw thanks a lot for all the great user support you're giving here!
Cheers,
/Manuel
 


Gabor





2013/4/24 Pedro Delgado Perez <pedro.delgadoperez at mail.uca.es [ mailto:pedro.delgadoperez at mail.uca.es ]>



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. 

Regards,

Pedro.

El dia 24 abr 2013 11:14, Gábor Kozár <kozargabor at gmail.com [ mailto:kozargabor at gmail.com ]> escribió:

Hi,

> And I only want to retrieve nodes inside class A (in A.h and A.cpp), but not inside B.h because I'm not interested in this class. How can I avoid this?



This is something you can't express with matchers, as you can only run them on AST nodes, and there is no AST node to represent header files (there is only TranslationUnitDecl, but that represents a whole translation unit, i.e. a cpp file with all included files).

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.

> We have considered 1 and 2, but not 3 nor 4. Imagine that we have the case 3 and I want to delete the constructor both in A.h(declaration) and A.cpp(definition). Do I have to prepare two different matchers to look for them? Or is there a way that, for example, I find the definition and then I can refer its declaration? Of course, I need to make sure that both, definition and declaration are deleted.



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.
Gabor




2013/4/24 Pedro Delgado Perez <pedro.delgadoperez at mail.uca.es [ mailto:pedro.delgadoperez at mail.uca.es ]>

Hi, 

Thank you for all your explanations, now everything is much clearer. But, please, let me ask you another last question regarding:




The problem for me is that I'll have to make some source-to-source translations: sometimes I'll have to modify the .cpp file and sometimes the .h (or even both of them) For instance, if i want to know if a certain method is declared as "virtual", I would need to examinate the .h file. Thus, I cannot exclude all .h files. So, how can I manage this?


Well, you exclude just the system header files in the match callback, as I've showed before, using SourceManager :: isInSystemHeader and isInExternCSystemHeader.
Ok, I see that i can exclude all the system headers, but imagine the next cpp:

#include "A.h"
#include "B.h"

A::A() {
... ...
}

int A::m() {
B b;  //B.h header has been included because it's needed in a member function of A
... ...
}

... ...

And I only want to retrieve nodes inside class A (in A.h and A.cpp), but not inside B.h because I'm not interested in this class. How can I avoid this?

In addition, in the matcher we've working on, we looked for default constructors declarations defined inline. But several options more were possible:


1. I have both declaration and definition inline in A.h
2. I have both declaration and definition inline in A.cpp
3. I have declaration in A.h and definition in A.cpp (the example above)
4. I have declaration and definition (but not inline) in A.cpp



We have considered 1 and 2, but not 3 nor 4. Imagine that we have the case 3 and I want to delete the constructor both in A.h(declaration) and A.cpp(definition). Do I have to prepare two different matchers to look for them? Or is there a way that, for example, I find the definition and then I can refer its declaration? Of course, I need to make sure that both, definition and declaration are deleted.

I hope you know what I mean. 



Thanks for everything Gábor, 

Pedro.





El dia 22 abr 2013 21:52, Gábor Kozár <kozargabor at gmail.com [ mailto:kozargabor at gmail.com ]> escribió:



Hi,
> I found isWritten() member for CXXCtorInitializer:
Nice find, I actually did not know about this.

> Ok. But I don't know where I should put or send these matchers to share them. Could you indicate me?


In the source code, the place for these is ASTMatchers.h. When you have something that you would like to propose to be integrated into the clang repository, I think what you need to do is send an e-mail to this mailing list, with the diff attached (that shows what changes you made), and ask for it to reviewed. But you probably should look at the website and see if there's any guideline for this - or just ask it on the mailing list.

> When you say "they allow you to run a matcher on the specified node, not the whole AST." you mean something like this?:


The code snippet you sent shows how to retrieve a node that has been accepted and bound by a matcher.

What I mean is that if you have a CXXRecordDecl* object for example (from whatever source), and you want to find some nodes in it that match a specific condition - for example, you want to check if another type is used anywhere within this specific C++ class - you can use clang::ast_matchers::match, because you only need the nodes that satisfy this condition inside the record declaration that you have, and not anywhere in the AST.
To be honest I'm not sure what causes the confusion here, I think this is fairly self-explanatory.
> The problem for me is that I'll have to make some source-to-source translations: sometimes I'll have to modify the .cpp file and sometimes the .h (or even both of them) For instance, if i want to know if a certain method is declared as "virtual", I would need to examinate the .h file. Thus, I cannot exclude all .h files. So, how can I manage this?


Well, you exclude just the system header files in the match callback, as I've showed before, using SourceManager :: isInSystemHeader and isInExternCSystemHeader.

> but it is still matching nodes in other files, such as ostream, bits/basic_ios.h or bits/streambuf_interator.h because I included the iostream header. I need to avoid all these nodes, but I don't know how to do it.


You'll need to show me some more code than that. How does your match callback function look like? What is FullLocation?

> I see that I can retrieve some nodes using matchers and then use a RecursiveASTVisitor on that nodes, but I can't clearly see the contrary: if I'm visiting only a kind of node, I know that I can directly use the methods of that class, but how could I use a matcher in the same way as in the example below?:


Both RecursiveASTVisitor and the matchers serve the exact same purpose, and they work in exactly the same way (in fact, the matchers use RecursiveASTVisitor internally) - the only different is that matchers are higher-level concepts, allowing for a more intuitive definition of match conditions. It's like a regular expression for ASTs.


When you work with matchers, you need two things: a matcher expression, constructed from the matcher functions like functionDecl(), isDefinition(), has(), allOf(), etc. and a match callback, i.e. a function that will be called for every AST node the matcher accepts while it is traversing the AST (i.e. running). You can use the .bind() method of the matchers to bind nodes accepted by the specified matcher to a name, and later retrieve it in the callback using result.Nodes.getNodeAs<T>. For example: functionDecl(has(compoundStmt().bind("c"))).bind("f"). When this matcher expression accepts an AST node, and runs the callback, you can access the matched FunctionDecl and CompoundStmt nodes by result.Nodes.getNodeAs<FunctionDecl>("f") and result.Nodes.getNodeAs<CompoundStmt>("c"), respectively. What you with these afterwards is up to you - if you want, you can even run another matcher on them using clang::ast_matchers::match, as I've already explained above.

In your example code, the matcher callback retrieves a bound node (a ForStmt) with the name of "forLoop", and then writes its AST to the console. For example you can use with this matcher expression: forStmt(unless(has(compoundStmt()))), which will cause the AST of all for loops whose body is just a single statement with the {} brackets to appear on the screen.
Gabor



2013/4/21 Pedro Delgado Perez <pedro.delgadoperez at mail.uca.es [ mailto:pedro.delgadoperez at mail.uca.es ]>


Hi,


This is indeed something I haven't considered, but should be easy to fix. Looking at the documentation for CXXCtorInitializer, you'll see that there's a member called isBaseInitializer(). The other thing you'll need to check (probably, if that is what you need) for is whether the base ctor call is implicit, which is probably done best by constraining the CXXConstructExpr with argumentCountIs(0). Putting together a custom matcher using these should be simple.

I found isWritten() member  for CXXCtorInitializer:
"Returns true if this initializer is explicitly written in the source code."
And finally, I accomplished what I wanted. Now, only B constructor is matched in:


class A{
   public: A(){}
};

class B: public A{
   public: int b, h;
      B():A(){b=0; h=0;}
};

class C: public A{
   public C(){}
};

But thanks for the members you have indicated: i'm sure I'll have to use them in the future. 



Also keep in mind that if you put together a generic and useful enough matcher, you should totally contribute it as a patch, so that others in need of a similar thing have it available in the future.
Ok. But I don't know where I should put or send these matchers to share them. Could you indicate me?



Yes, you need to use these in the matcher callback. It is indeed inefficient, but we've been unable to come up with any better solution. The problem is in the underlying compiler technology, i.e. the nature of header files.

> Is it possible to search for nodes only in some files indicated by the user?


Sure, take a look at the clang::ast_matchers::match functions - they allow you to run a matcher on the specified node, not the whole AST. Unfortunately I do not think this will help you in this case, as you cannot distinguish the parts of the TU coming from system header files and the parts coming from user files at the AST level.
Ok, that's a setback i should have in mind. When you say "they allow you to run a matcher on the specified node, not the whole AST." you mean something like this?:
Result.Nodes.getNodeAs<clang::ForStmt>("forLoop"))
This is the way I retrieve the nodes I need to match at this moment.

The problem for me is that I'll have to make some source-to-source translations: sometimes I'll have to modify the .cpp file and sometimes the .h (or even both of them) For instance, if i want to know if a certain method is declared as "virtual", I would need to examinate the .h file. Thus, I cannot exclude all .h files. So, how can I manage this? 


> I have seen that every file has "id" and, for instance, instead of using "isInSystemHeader" and "isInExternCSystemHeader" could i do the next?:



I'm not sure I understand what you're trying to do here... As the error you're getting, it's because getSourceManager is missing the paranthesis, i.e. the () that would indicate it's a method call.
What I was trying to do is to examinate the nodes only from the file provided by the user in the execution (for instance, if I run bin/default-constructor test.cpp, I only want the nodes from test.cpp) I tought that with member getMainFileID() I would achieve what I wanted, but this isn't working as expected (sorry for the error of getSourceManager(), but I tested it really quick and late only to write the message). I have also tried with:
if (!Context->getSourceManager().isInSystemHeader(FullLocation) && ! Context->getSourceManager().isInExternCSystemHeader(FullLocation)){
... 
}

but it is still matching nodes in other files, such as ostream,  bits/basic_ios.h or bits/streambuf_interator.h because I included the iostream header. I need to avoid all these nodes, but I don't know how to do it.


Yes, that's quite possible, as I'm using clang 3.2. Nonetheless, you should be able to figure out what the issue is, as I've given you a draft (a pattern, if you will).
Ok. I'm going to check this like you taugth me ;)

And a last question if you don't mind. I based my examples for the moment in the matcher shown in:
http://clang.llvm.org/docs/LibASTMatchersTutorial.html [ http://clang.llvm.org/docs/LibASTMatchersTutorial.html ]
But you told me that it's possible to merge the usage of Matchers and RecursiveASTVisitor as in:
http://clang.llvm.org/docs/RAVFrontendAction.html [ http://clang.llvm.org/docs/RAVFrontendAction.html ]
I see that I can retrieve some nodes using matchers and then use a RecursiveASTVisitor on that nodes, but I can't clearly see the contrary: if I'm visiting only a kind of node, I know that I can directly use the methods of that class, but how could I use a matcher in the same way as in the example below?:
virtual void run(const MatchFinder::MatchResult &Result) {    if (const ForStmt *FS = Result.Nodes.getNodeAs<clang::ForStmt>("forLoop"))      FS->dump();  }
I hope you can understand what I mean.

Thank you for all your help,

Pedro


El dia 21 abr 2013 01:43, Gábor Kozár <kozargabor at gmail.com [ mailto:kozargabor at gmail.com ]> escribió:



Hi,
> The default constructor of C is also matched as there is an implicit call to the default constructor of class A (and effectively, this is an expression and not a declaration as I said in the last message). So, I've been thinking about it and, though I don't have the solution, I'm quite sure we have to change "anything()" inside "hasAnyConstructorInitializer()" to avoid this exception. Any suggestion?


This is indeed something I haven't considered, but should be easy to fix. Looking at the documentation for CXXCtorInitializer, you'll see that there's a member called isBaseInitializer(). The other thing you'll need to check (probably, if that is what you need) for is whether the base ctor call is implicit, which is probably done best by constraining the CXXConstructExpr with argumentCountIs(0). Putting together a custom matcher using these should be simple.

Also keep in mind that if you put together a generic and useful enough matcher, you should totally contribute it as a patch, so that others in need of a similar thing have it available in the future.
> On the other hand, I've been trying to use the methods you told me, but I have to use those methods after the matcher execution, haven't I? This is a bit inefficiently as the mathcer is looking up in some files that are not needed.


Yes, you need to use these in the matcher callback. It is indeed inefficient, but we've been unable to come up with any better solution. The problem is in the underlying compiler technology, i.e. the nature of header files.

> Is it possible to search for nodes only in some files indicated by the user?


Sure, take a look at the clang::ast_matchers::match functions - they allow you to run a matcher on the specified node, not the whole AST. Unfortunately I do not think this will help you in this case, as you cannot distinguish the parts of the TU coming from system header files and the parts coming from user files at the AST level.


> I have seen that every file has "id" and, for instance, instead of using "isInSystemHeader" and "isInExternCSystemHeader" could i do the next?:



I'm not sure I understand what you're trying to do here... As the error you're getting, it's because getSourceManager is missing the paranthesis, i.e. the () that would indicate it's a method call.
> Umm... What a strange thing... I will get over this one more time and see if I did something wrong.
Maybe something is missing or is different in AStMatchersInternal or ASTMatchersMacros.
Yes, that's quite possible, as I'm using clang 3.2. Nonetheless, you should be able to figure out what the issue is, as I've given you a draft (a pattern, if you will).

Good luck!
Gabor



2013/4/21 Pedro Delgado Perez <pedro.delgadoperez at mail.uca.es [ mailto:pedro.delgadoperez at mail.uca.es ]>


Hi and thanks again,

I clearly expressed incorretly the problem. I'll try to explain it more in detail:

If we have the classes below:

class A{
   public: A(){}
};

class B: public A{
   public: int b, h;
      B():A(){b=0; h=0;}
};

class C: public A{
   public C(){}
};

I want my matcher retrieves ONLY the default constructor declaration of B. However this is what happened with the matcher you proposed me:

CXXConstructorDecl 0xa1f6080 </home/pedro/clang-llvm/build/testClases.cpp:14:3, col:25> B 'void (void)'
|-CXXCtorInitializer 'class A'
| |-CXXConstructExpr 0xa1f6608 <col:8, col:10> 'class A' 'void (void)'
`-CompoundStmt 0xa1f6710 <col:11, col:25>
 |-BinaryOperator 0xa1f6698 <col:12, col:16> 'int' lvalue '='
 | |-MemberExpr 0xa1f6660 <col:12> 'int' lvalue ->b 0xa1f6100
 | | `-CXXThisExpr 0xa1f6650 <col:12> 'class B *' this
 | `-IntegerLiteral 0xa1f6680 <col:16> 'int' 0
 `-BinaryOperator 0xa1f66f8 <col:19, col:23> 'int' lvalue '='
   |-MemberExpr 0xa1f66c0 <col:19> 'int' lvalue ->h 0xa1f6140
   | `-CXXThisExpr 0xa1f66b0 <col:19> 'class B *' this
   `-IntegerLiteral 0xa1f66e0 <col:23> 'int' 0
Found declaration at 14:3
CXXConstructorDecl 0xa1f68b0 </home/pedro/clang-llvm/build/testClases.cpp:25:3, col:7> C 'void (void)'
|-CXXCtorInitializer 'class A'
| |-CXXConstructExpr 0xa1f6c08 <col:3> 'class A' 'void (void)'
`-CompoundStmt 0xa1f6c58 <col:6, col:7>
Found declaration at 25:3

The default constructor of C is also matched as there is an implicit call to the default constructor of class A (and effectively, this is an expression and not a declaration as I said in the last message). So, I've been thinking about it and, though I don't have the solution, I'm quite sure we have to change "anything()" inside "hasAnyConstructorInitializer()" to avoid this exception. Any suggestion?


On the other hand, I've been trying to use the methods you told me, but I have to use those methods after the matcher execution, haven't I? This is a bit inefficiently as the mathcer is looking up in some files that are not needed. Is it possible to search for nodes only in some files indicated by the user? Normally, a class is declared in a .h file and defined in the .cpp file and i would like to search in both of them.
I have seen that every file has "id" and, for instance, instead of using "isInSystemHeader" and "isInExternCSystemHeader" could i do the next?:

class DefaultConstructor : public MatchFinder::MatchCallback {
public :
 virtual void run(const MatchFinder::MatchResult &Result) {
 ASTContext *Context = Result.Context;
 FileID mainFileID = Context->getSourceManager.getMainFileID();
 if (const CXXConstructorDecl *FS = Result.Nodes.getNodeAs<clang::CXXConstructorDecl>("methods")){
     FullSourceLoc FullLocation = Context->getFullLoc(FS->getLocStart());
     if (FullLocation.isValid() && FullLocation.getFileID() == mainFileID)
       ... ...
   }
 }
};

( I got an error with this: reference to non-static member function must be called
 FileID mainFileID = (Context->getSourceManager).getMainFileID();
                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~ )


> Thank you for your time Gábor. I have put this, but I don't know why it doesn't fetch any nodes at all... Could you test this?


I did test it, and worked fine for me. Not sure what could be the issue.

Umm... What a strange thing... I will get over this one more time and see if I did something wrong.
Maybe something is missing or is different in AStMatchersInternal or ASTMatchersMacros.

Thanks,

Pedro.


El dia 19 abr 2013 16:28, Gábor Kozár <kozargabor at gmail.com [ mailto:kozargabor at gmail.com ]> escribió:








Hi,

> Thank you for your time Gábor. I have put this, but I don't know why it doesn't fetch any nodes at all... Could you test this?


I did test it, and worked fine for me. Not sure what could be the issue.

> An implicit node is detected: the default constructor of class A in the list of constructors in default constructor of class B. So, I tried to fix this doing  this:

I believe this is what you need then, as Manuel suggested:

constructorDecl(isDefinition(), parameterCountIs(0), unless(isImplicit()),

      anyOf(hasAnyConstructorInitializer(anything()), has(compoundStmt(has(stmt())))));
How you compose your matchers dictate how they will behave. Lets take a simple example: functionDecl(isDefinition()). Here the fact that isDefinition() was given as a parameter to functionDecl() indicates that it refines that matcher, i.e. imposes further conditions that have to be met in order for a node to be matched.
Now with this logic, lets look at what you tried: withInitializer(constructorDecl(isImplicit()))

This means something like "an initializer that is an implicit constructor declaration" - which obviously makes no sense, and thanks to template voodoo magic, it doesn't compile either. The reason is that withInitializer expects a Matcher<Expr>, that is, a matcher that matches certain Exprs (that meet a certain criteria). constructorDecl() yields a Matcher<CXXConstructorDecl>, because it is a matcher that accepts CXXConstructorDecl objects.

> In addition, I would like to work only with the code that is explicit and for example when I try to match "methodDecl(isOverride())" a lot of implicit methods  (and even methods from other files apart of mine) are detected with this matcher. How can I avoid this?

I'm not sure what you mean by "implicit" methods here. Obviously you'll get matches in header files as well, most notably, system header files. SourceManager::isInSystemHeader and isInExternCSystemHeader is what you're looking for if you want to avoid that - you'll place such a check in your matcher callback function.

Gabor




2013/4/19 Pedro Delgado Perez <pedro.delgadoperez at mail.uca.es [ mailto:pedro.delgadoperez at mail.uca.es ]>


Thank you ver much both of you, it really helps:


All of the ways you cite make sense. What you want really depends on what kind of control you want. Note that you can always easily start with AST matchers to find higher level things you're interested in, and then drill down through the AST nodes by calling the methods or even by using a RecursiveASTVisitor on a node...
 Ok, Manuel. I need to study this a bit more to catch on the best way for me, but it's good to know I can merge both strategies.


I have put together quickly the matcher that I believe suits your needs, just so that you can see how it works:

namespace clang {
namespace ast_matchers {

using namespace clang::ast_matchers::internal;

AST_MATCHER(CXXConstructorDecl, defaultNonTrivialCtor)
{
   return Node.isThisDeclarationADefinition()
      && Node.isDefaultConstructor()
      && (Node.getNumCtorInitializers() != 0 || !Node.hasTrivialBody());
}

} // ast_matchers
} // clang


(Don't forget to include ASTMatchers.h, ASTMatchersInternal.h and ASTMatchersMacros.h)

Thank you for your time Gábor. I have put this, but I don't know why it doesn't fetch any nodes at all... Could you test this?


constructorDecl(isDefinition(), parameterCountIs(0),
      anyOf(hasAnyConstructorInitializer(anything()), has(compoundStmt(has(stmt())))));

(I did a quick test, and seems to work as intended, but you should make sure to test it thoroughly yourself.)
I have put this as well and this time does it works, but indeed it needs something more, because if we have:

class A{
public:
A(){}
... 
};

class B: public A{
public:
B(){}
...
};

An implicit node is detected: the default constructor of class A in the list of constructors in default constructor of class B. So, I tried to fix this doing  this:

constructorDecl(isDefinition(), parameterCountIs(0),
      anyOf(hasAnyConstructorInitializer(unless(withInitializer(constructorDecl(isImplicit()))))), has(compoundStmt(has(stmt())))));

But, I newbie in this and it doesn't work as constructorDecl returns a Decl and withInitializer a Expr (i think). How could I do this? Sorry for this, but I would like to have at least an example complete. 

In addition, I would like to work only with the code that is explicit and for example when I try to match "methodDecl(isOverride())" a lot of implicit methods  (and even methods from other files apart of mine) are detected with this matcher. How can I avoid this?

Thanks,

Pedro.

El dia 19 abr 2013 13:50, Manuel Klimek <klimek at google.com [ mailto:klimek at google.com ]> escribió:


On Fri, Apr 19, 2013 at 12:18 PM, Pedro Delgado Perez <pedro.delgadoperez at mail.uca.es [ mailto:pedro.delgadoperez at mail.uca.es ]> wrote:




Hi again,

Well, I've just understood that not all the methods in a class have a matcher related. For instance, I'm trying to match the default constructor declaration of a class:

class Foo {
public:
Foo(){}
Foo(int a){... ...}
}


And in CXXConstructorDecl we have isDefaultConstructor(), but I can't find an AST_MATCHER to do this. So, I suppose I would have to implement a new AST_MATCHER like this:

AST_MATCHER(CXXConstructorDecl, isDefaultConstructor){
return Node.isDefaultConstructor();
}

Wouldn't it? But, this happens often, so... would you recommend me use AST_MATCHERS? Or it would be better to do something like it is explained in http://clang.llvm.org/docs/RAVFrontendAction.html [ http://clang.llvm.org/docs/RAVFrontendAction.html ] ? This way, I can directly use the methods in the classes. For instance:
 bool VisitCXXConstructorDecl(CXXConstructorDecl *Declaration) {    if (Declaration->isDefaultConstructor()) {
I have to visit a lot of kind of nodes with different features, not only this. 

All of the ways you cite make sense. What you want really depends on what kind of control you want. Note that you can always easily start with AST matchers to find higher level things you're interested in, and then drill down through the AST nodes by calling the methods or even by using a RecursiveASTVisitor on a node...
Cheers,
/Manuel
 

Please, I need a path to get down to work.

Thanks in advance,


Pedro.


El dia 19 abr 2013 01:58, Gábor Kozár <kozargabor at gmail.com [ mailto:kozargabor at gmail.com ]> escribió:



Hi,


What version are you using? The matchers isOverride() and isVirtual() I know for certain were not in version 3.2, and can only be found on SVN (in this file: http://llvm.org/svn/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h [ http://llvm.org/svn/llvm-project/cfe/trunk/include/clang/ASTMatchers/ASTMatchers.h ]).

Nonetheless, you can implement them all very easily manually, or just indeed copy their implementation from the link above. Also, instead of isDefaultConstructor(), you could use argumentCountIs(0).

Gabor




2013/4/18 Pedro Delgado Perez <pedro.delgadoperez at mail.uca.es [ mailto:pedro.delgadoperez at mail.uca.es ]>


Hi,

I'm newbie using ASTMatchers and I'm trying to learn little by little how to use them.

I was basing on the matcher recordDecl(hasName("Foo"), isDerivedFrom("Bar")) shown in http://clang.llvm.org/docs/LibASTMatchers.html [ http://clang.llvm.org/docs/LibASTMatchers.html ] trying to include new features. For instance, I tried to look for classes which have at least one virtual method:

recordDecl(hasName("Foo"), isDerivedFrom("Bar"), hasMethod(isVirtual()))

Or I tried to match protected overriden methods:

methodDecl(allOf(isProtected(), isOverride());

But neither of them worked as it couldn't find "isOverride" and "isVirtual" identifiers. I was trying a lot of combinations, but I can't understand this well.

Finally, I tried to look for the the default constructor of a certain class:

constructorDecl(hasName("Foo"), isDefaultConstructor())

but this is wrong. What I'm doing bad? Please, any information you give me will be fine to me to understand how to use matchers.

Thanks in advance,

Pedro.



_______________________________________________
cfe-dev mailing list
cfe-dev at cs.uiuc.edu [ mailto:cfe-dev at cs.uiuc.edu ]

http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev [ http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev ]


_______________________________________________
cfe-dev mailing list
cfe-dev at cs.uiuc.edu [ mailto:cfe-dev at cs.uiuc.edu ]

http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev [ 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/20130426/7bc85eb9/attachment.html>