[cfe-dev] clang AST printer

[Dmitri Gribenko]

On Fri, Sep 21, 2012 at 6:44 PM, Manuel Klimek <klimek at google.com> wrote:
> On Fri, Sep 21, 2012 at 5:40 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
>> On Fri, Sep 21, 2012 at 6:37 PM, Manuel Klimek <klimek at google.com> wrote:
>>> On Fri, Sep 21, 2012 at 5:32 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
>>>> On Fri, Sep 21, 2012 at 4:21 PM, Alexander Kornienko <alexfh at google.com> wrote:
>>>>>
>>>>> 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.
>>>>
>>>> Does this mean that current declaration printer will be removed?  I
>>>> see value in having a decl printer that prints declarations in
>>>> user-readable form, so I think we should keep it until clang-format
>>>> will be here.
>>>
>>> I'd be curious what your use case is - after all, it'll only print
>>> declrations in user-readable form, and all the other stuff will be
>>> written in S-epxression-like syntax.
>>
>> The decl printer could be used to pretty-print decls in some
>> clang-based documentation generation system.
>>
>>> If we want a pretty-printer, I'd expect -pretty-print and not
>>> -ast-dump to trigger that?
>>
>> I'd just leave it as an API.
>
> I'm not sure what you mean by that. I agree that there are use cases
> for a pretty printer, but I think "half" of the ast-dump mechanism is
> a bad place to have a pretty printer...

Imagine a Clang-based Doxygen-like tool.  Not only we need to extract
documentation comments and format them, we also need to pretty-print
declarations to display them along with documentation.  So only decl
printer is useful.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/