Announcement: EOL of cppast

[foonathan]

I think cppast has reached the end of its usefulness.

• I have no longer a personal use case for cppast, so I am not motivated to spend my free time on it.
• It is missing many modern post-C++17 features and requires a lot of work to bring it up to date. I no longer have the time for it.
• clang has learned the ability to dump the AST as JSON, which is better than cppast in any way: It works for everything clang is able to compile, gives more information, and also supports statements and expressions.
• In principle, we could give cppast another frontend that parses the JSON output and creates the cppast data structures from it. I've started that in feature/json, but don't have the time to finish it.

So I recommend everybody that is still using cppast to migrate over to the AST clang dump. Running clang++ -fsyntax-only -Xclang -ast-dump=json file.cpp will output the AST as JSON, which can then be trivially parsed using e.g. python to do whatever is necessary. The only downside is that clang doesn't guarantee stability of the AST output.

So unless someone is willing to step up and maintain cppast by 2023-08-01 I will archive the repository. Thanks for all the stars and users and I'm sorry if I've let you down.

[jyapayne]

Do you know of a way to get the macro defs? AFAIK the JSON dump still doesn't output these.

[deadlocklogic]

I really understand your choice, and this is usually the lifecycle of open source projects.
But for me it is a pity because I've built a complete tool around cppast and now I don't know how to move on (maybe CppSharp can be a choice dunno?). Haven't tried json dump before, does it work on many translation units just like cppast works?

[foonathan]

Do you know of a way to get the macro defs? AFAIK the JSON dump still doesn't output these.

You can use clang++ -E -dD file.cpp to get all macros defined in the translation units. Note that this includes macros defined in included header file, but this can be filtered by grepping for #define NAME in the source code afterwards.

But for me it is a pity because I've built a complete tool around cppast and now I don't know how to move on (maybe CppSharp can be a choice dunno?).

cppast will continue to work as well as it does right now. If that's fine, you don't need to do anything. Alternatively, you can volunteer to maintain it - I'll happily transfer ownership.

Haven't tried json dump before, does it work on many translation units just like cppast works?

You need to invoke clang on all translation units yourself.

---

I realize that there is value in a tool built on top of clang's JSON dump - I've started it in the json branch. I just don't have the time to continue it.

[deadlocklogic]

The project in current status is stable IMHO, so stopping adding features is reasonable but neglecting bug fixes renders the main branch obsolete.

cppast will continue to work as well as it does right now. If that's fine, you don't need to do anything. Alternatively, you can volunteer to maintain it - I'll happily transfer ownership.

Newer versions of clang (16.0.0+) are breaking the tests.

json branch is interesting but personally never had experience with it.
Maintaining the project is a challenge for a person with minor experience in compilers interface, let alone patching libclang functionality.
For me, I will stick with latest version with libclang 15.0.7, while trying newer alternatives like CppSharp (it is built around libclang too but more precise, it is using the frontend which is not available through Cindex and seems capable of accurate template manipulation).

Thanks for your efforts anyway.

[SirLynix]

I'm a cppast user and I tried to switch to Clang ast-dump, Clang takes about ten seconds to generate a 400MB json of 8M lines (almost exclusively made of implicit declarations and included headers, and about 10k lines for the file).

So I think I'll just stick to cppast 😄

[mavavilj]

The only downside is that clang doesn't guarantee stability of the AST output

What do you mean by this? Any sources?