ASTMatchers: isVirtual and isOverride

Hi,

You’ll have one process(Decl*) method that does all the common stuff, and overloads for more specific types as needed, e.g. process(FunctionDecl*), which then call the Decl* overload by explicit casting. Have overload resolution work for you.

Ok, I think the best in my case is to have a process method per matcher, so don’t take care of this anymore.

Now, I have other two or three questions spinning in my mind.

  1. Imagine that I have two files to process in the same execution and both include the same header file. Will that header file’s code be processed twice? In this case, how could I avoid this?

  2. A matcher finds a CXXConstructorDecl node in a header file (we can call it X.h):
    -first: I need to inform the cpp files that include X.h that the header has changed. How can I find that files? Up to now, I was only proccesing one file and searched for the file through Context->getSourceManager().getMainFileID() (That I suppose is the file which have the main method implemented, but I’m not absolutely sure). But now, I need to find another way to find these cpp files.

  3. Is there a way to stop the traversal of the AST in a certain moment when, for instance, I find what I was looking for?

Thanks in advance,

Pedro.

El dia 14 may 2013 21:13, Gábor Kozár kozargabor@gmail.com escribió:

Hi,

You'll have one process(Decl*) method that does all the common stuff, and
overloads for more specific types as needed, e.g. process(FunctionDecl*),
which then call the Decl* overload by explicit casting. Have overload
resolution work for you.

Ok, I think the best in my case is to have a process method per matcher,
so don't take care of this anymore.

Now, I have other two or three questions spinning in my mind.

1. Imagine that I have two files to process in the same execution and both
include the same header file. Will that header file's code be processed
twice? In this case, how could I avoid this?

Yes. You don't want to avoid this, you want to fix it afterwards by
deduplicating your results.

2. A matcher finds a CXXConstructorDecl node in a header file (we can call
it X.h):
-first: I need to inform the cpp files that include X.h that the header
has changed. How can I find that files? Up to now, I was only proccesing
one file and searched for the file through
Context->getSourceManager().getMainFileID() (That I suppose is the file
which have the main method implemented, but I'm not absolutely sure). But
now, I need to find another way to find these cpp files.

You'll want to write a matcher that matches all calls to the
CXXConstructorDecl.

3. Is there a way to stop the traversal of the AST in a certain moment
when, for instance, I find what I was looking for?

No. Why would you want to do that? Traversing the AST is super cheap
compared to parsing the C++ code.

Hi,

1. Imagine that I have two files to process in the same execution and both include the same header file. Will that header file’s code be processed twice? In this case, how could I avoid this?

Sorry, this is sounding like you’re expecting us to solve all your issues. You can answer your own question by doing a very simple test, but otherwise the answer is yes - which is also a no-brainer if you know how the C++ compilation model works. Anyhow, just to give you a pointer: you can store the FileIDs or filenames already processed, check against this list when processing a file, and clear this list when starting a new TU. All the information you need was already mentioned in the mailing list (in fact, even in this discussion), and you can always refer to the documentation.

> But now, I need to find another way to find these cpp files.

Again: RTFM. The SourceManager class is what you need.

Is there a way to stop the traversal of the AST in a certain moment when, for instance, I find what I was looking for?

No, as Manuel already mentioned, it’s pointless. You can set a flag and just return from the callback if the flag is true.

Sorry if I’m sounding harsh - I’m more than happy to help with any reasonable questions, but we’ve already taught you everything you need. In fact, you should have been able to learn all this without us - I myself have learned this mostly through experimentation, reading the documentation and the Clang source code. This is the way you can learn effectively.

Good luck!

Gabor