[cfe-dev] clang AST printer

Fri Sep 21 06:21:39 PDT 2012

On Fri, Sep 21, 2012 at 2:40 PM, Manuel Klimek <klimek at google.com> wrote:

> On Fri, Sep 21, 2012 at 12:32 PM, Philip Craig <philipjcraig at gmail.com>
> wrote:
> > On Fri, Sep 21, 2012 at 7:49 PM, Manuel Klimek <klimek at google.com>
> wrote:
> >> Hi Philip,
> >>
> >> we had a discussion around the strategy for handling ast dumping
> >> fairly recently. I think the common agreement in the end was that
> >> instead of having an extra tool, we want to make clang's -ast-dump
> >> awesome.
> >
> > Was this discussion on the mailing list? Any chance you could point me
> to it?
>
>
> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20120716/060831.html
>
> >> I don't know what your ultimate goal is here, but from my
> >> side any work that goes towards making clang -ast-dump better would be
> >> highly appreciated :)
> >
> > My motivation was having some way of getting the structure of the AST
> > for a given piece of source code, so that it is easier to correctly
> > call the AST matchers to match that code. The issue with clang
> > -ast-dump is that it pretty prints decls and types. So would the goal
> > here be to add more command line options to clang to control how
> > -ast-dump prints the AST?
>
> No, I think the goal is to dump decls and types in a sensible way :)
>

More specifically, I think we agreed on changing -ast-dump from
pretty-printing declarations to outputting them in the same LISP-style
format, which is used for statements. I was going to implement that, but
never had time to do this. If you're going to continue work on your
utility, it would be much more valuable, if you instead improved clang's
current -ast-dump option. In that case you consider to go this way, here's
where to start:

clang/lib/Frontend/ASTConsumers.cpp:120: ASTConsumer
*clang::CreateASTDumper(StringRef FilterString)

is a common entry point, used by "clang -cc1 -ast-dump" and by "clang-check
-ast-dump". An additional benefit from this would be that after "-ast-dump"
starts outputting the AST for declarations in a structured form,
"-ast-dump-xml" will become useless and can be removed.

-- 
Regards,
Alex

> > Are there any other areas where you think -ast-dump needs to be better?
>
> As you said, decls and types need to be structured nicely. Also, a
> while ago Richard proposed a patch to add coloring, no idea how far he
> got (cc'ing him)
>
> Cheers,
> /Manuel
>
> >
> >>
> >> Cheers,
> >> /Manuel
> >>
> >> On Fri, Sep 21, 2012 at 1:17 AM, Philip Craig <philipjcraig at gmail.com>
> wrote:
> >>> Hi,
> >>>
> >>> I've been writing a tool to print a clang AST. You can find it at
> >>> https://github.com/philipc/clang-ast. I've been mostly writing this as
> >>> a learning exercise, but I would like to see if there is any wider
> >>> interest in the tool.
> >>>
> >>> I'm new to clang, and interested in working on tooling. For this task,
> >>> it is important to have an understanding of the AST. I've found the
> >>> documentation at http://clang.llvm.org/docs/InternalsManual.html and
> >>> http://clang.llvm.org/docs/IntroductionToTheClangAST.html (is there
> >>> any more?), but I think it would be helpful to be able to print the
> >>> AST for source code to see how it is used in practice. I've found two
> >>> ways to do this currently, which aren't quite what I wanted:
> >>>
> >>> clang --ast-dump
> >>> - pretty prints some parts, has too much internal info, more suited
> >>> for debugging use by clang developers
> >>>
> >>> clang --ast-dump-xml
> >>> - incomplete and XML is too verbose for this purpose
> >>>
> >>> Since RecursiveASTVisitor seems to be the API that will be used by
> >>> tool developers, I've been using RAV to print the AST. I've found a
> >>> few minor bugs in RAV as a result of this, which I'm in the process of
> >>> submitting.
> >>>
> >>> One limitation of RAV is that the Visit methods aren't given
> >>> information about their relationship with their parent, so the tool
> >>> can only list all the children of a node, without distinguishing
> >>> between the LHS and RHS of an operator, for example. Is there any
> >>> desire to extend RAV to be able to do this?
> >>>
> >>> I've been writing small code snippets to test printing the various
> >>> parts of the AST. If you want to see examples of the output of the
> >>> tool, this is included in the test cases. As a quick example, "void
> >>> foo() {}" is printed as:
> >>>
> >>>   FunctionDecl
> >>>     DeclarationName foo
> >>>     FunctionNoProtoType
> >>>       BuiltinType void
> >>>     CompoundStmt
> >>>
> >>> Finally, I've been trying to give a textual description of the AST
> >>> grammar in https://github.com/philipc/clang-ast/blob/master/ast.txt.
> >>> This is an attempt to give something similar to
> >>> http://docs.python.org/py3k/library/ast.html#abstract-grammar. I'm not
> >>> sure if it is turning out to be that useful though.
> >>>
> >>> Any comments welcome!
> >>>
> >>> Thanks,
> >>> Philip
> >>> _______________________________________________
> >>> cfe-dev mailing list
> >>> cfe-dev at cs.uiuc.edu
> >>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120921/545e1db1/attachment.html>