On Tue, Nov 27, 2018 at 4:50 AM Stephen Kelly via cfe-commits <cfe-commits@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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
