[cfe-dev] Any policy regarding changes in libtooling

[David Blaikie]

On Wed, Aug 13, 2014 at 10:15 AM, Mathieu Mérineau <mathineau at gmail.com> wrote:
> 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.

http://clang.llvm.org/docs/Tooling.html 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