CDT's AST is not designed to scale to an entire project. Once you start getting into the 10000+ LOC range, it's likely to start performing pretty badly.
For cross-file analysis purposes, CDT has an indexer, which parses each file in the project (one at a time), and builds a database of information about the code in the project as a whole (called the index). The index is accessed via the interface IIndex
, an instance of which can be obtained (for example) by calling IASTTranslationUnit.getIndex()
on any AST.
Most code analysis and manipulation use cases fall into one of the following workflows:
Just use the index. IIndex
gives you a lot to work with, such as:
- various overloads of
findBindings()
to find bindings matching a name or name prefix
findReferences(binding)
to give you all references to a binding
findDeclarations(binding)
to give you all declarations of a binding
and many others. This is how editor navigation features like Open Declaration and Call Hierarchy work.
Use the index to identify a small set of source files for which you need ASTs, and then parse those. This is how refactorings work. For example, the rename refactoring uses the index to locate uses of the binding being renamed, and then creates ASTs for the files containing those uses to perform the refactoring on.
If neither of the above is good enough and you really need AST-level information for every file in the project, create an AST for every file in the project, one at a time, and extract the information you need from each one. This is how the indexer itself works. (Note that, if you choose this option, you don't need to navigate includes to list all the files you need to parse. Instead, you can just enumerate all the files in the project. See PDOMRebuildTask.createDelegate()
for an example.)
If you say more about what your use case is, I may be able to provide more specific suggestions.