ASTMatchers: isVirtual and isOverride

Clang Frontend
1

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

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) :slight_smile:

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@google.com escribió:

2

Hi,

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

Ah, yes, that happens a lot to me as well. Now that I think about it, it
might be worthwhile adding a parameterless .bind() and .getNodeAs<T>() for
situations where only one node is bound. Should be fairly trivial, but also
not all that useful...

Thanks both! Now I can see all this much clearer and I have the enough
knowledge to start out with clang.

You're welcome. Good luck!

3

Hi,

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

Ah, yes, that happens a lot to me as well. Now that I think about it, it
might be worthwhile adding a parameterless .bind() and .getNodeAs<T>() for
situations where only one node is bound. Should be fairly trivial, but also
not all that useful...

Just use the empty string for binding and getNodeAs :slight_smile:

4

Just use the empty string for binding and getNodeAs :slight_smile:

That would potentially lead to confusion when there are more nodes bound,
but the programmer forgot to supply the proper name. In my suggestion, the
parameterless getNodeAs would have an assert to check there is exactly one
node bound (and whose name is the default name).

5

Just use the empty string for binding and getNodeAs :slight_smile:

That would potentially lead to confusion when there are more nodes bound,
but the programmer forgot to supply the proper name. In my suggestion, the
parameterless getNodeAs would have an assert to check there is exactly one
node bound (and whose name is the default name).

If you put everything behind constants, I think it'll be easy enough to see
what's happening - and that's a generally good strategy anyway, as you get
a compile error if you mistype...
Thus, I think it'd not add enough value to special case the interface.

6

That makes sense. It was just a stray thought.