Any policy regarding changes in libtooling

Hi all,

I’m currently working on a tool which exports the AST of C/C++ source code into XML format. I plan to eventually share the tool, but that’s not the purpose of my message for the moment.

I’m using libtooling and have inherited from RecursiveASTVisitor. This looks like the best way to visit the entire AST.

My tool currently works with Clang version 3.4.1. I was wondering if with further versions, the AST would be slightly different as it may be a concern for me as I plan to further implement some static code analysis which will rely on the AST. Purposely, I upgraded my Clang version to the one which is on SVN (rev 215502) and tried to recompile my tool.

I found out that, for the moment, there isn’t any difference in the AST, although there are some major changes in some class interfaces.

As examples,

FunctionDecl::getResultType() as been renamed to getReturnType().
This doesn’t make a big difference, but it’s enough to potentially break any tool depending on libtooling. In this case, getResultType could have been kept as an alias and marked as deprecated.

ASTFrontendAction::CreateASTConsumer() now returns an unique_ptr<ASTConsumer> instead of an ASTConsumer*. When you override this method, it is necessary to change the return type.

My question is, finally, is there any policy in Clang regarding changes made in the source code? Any intent to keep third-party tool depending on libtooling from being broke between each revision?



The LLVM C++ API has no guarantee of stability - it can and does
change frequently, without warning and without backwards compatibility
in mind. mentions that libclang, the
Clang C API should be used when "need a stable interface that takes
care to be backwards compatible"

But it comes with its own costs, of course.

- David