[cfe-dev] Dumping AST information to other formats

[Aaron Ballman via cfe-dev]

On Tue, Nov 27, 2018 at 4:50 AM Stephen Kelly via cfe-commits
<cfe-commits at lists.llvm.org> wrote:
>
> 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.

Thank you for passing this along -- it's actually somewhat aligned
with what I was envisioning. I very much like splitting out the
traversal and the printing mechanisms.

Would you like to be included on the review thread when I submit a patch?

~Aaron