Dumping AST information to other formats

[Stephen Kelly via cfe-commits]

On 26/11/2018 19:20, Aaron Ballman via cfe-commits wrote:
> Once upon a time, there was -ast-print-xml. This -cc1 option was
> dropped because it was frequently out of sync with the AST data. It is
> right to ask: why would JSON, etc be any different? This is still an
> open question, but a goal of this implementation will be to ensure
> it's easier to maintain as the AST evolves. However, this feature is
> intended to output a safe subset of AST information, so I don't think
> this feature will require any more burden to support than -ast-dump
> already requires (which is extremely limited). 

> I wanted to see if there were concerns or implementation ideas the
> community wanted to share before beginning the implementation phase of
> this feature.

Hi Aaron,

As you know, I've already done some work in this area.

I split the ASTDumper.cpp into multiple classes so that the traversal of 
the AST is separate to the printing of it to the output stream. You can 
see the proof of concept here:

  https://github.com/steveire/clang/commits/extract-AST-dumping

though it is not ready for a real review. I just extracted it to a 
branch for the purpose of this mailing list reply.

In my branch there are two implementations of outputter - one detailed 
and one 'simplified' AST. You can see the difference here:

  http://ec2-52-14-16-249.us-east-2.compute.amazonaws.com:10240/z/JuAvs8

Because the traversal is in a separate class, it should be possible to 
port ASTMatchFinder.cpp to use it, which will eliminate the class of 
bugs that arise due to ASTMatchFinder.cpp currently using RAV. Here is 
one such bug:

  https://bugs.llvm.org/show_bug.cgi?id=37629

but there are others for example relating to getting to a 
CXXConstructorDecl from a CXXCtorInitializer, so it is a class of bug 
rather than a single bug.

Because the traversal is in a separate class, you should be able to also 
implement it for different output formats without a significant 
maintenance burden.

Using this approach, the output formats will not get out of sync and 
fall to the same fate as the XML output feature.

Let me know if you're interested.

Thanks,

Stephen.