Hi Barry,
> Can it handle code with all the CPP crap we have (how does the CPP
> stuff fit in the AST)? Can you make a make clangify rule in the makefile
> similar to make uncrustify so we can verify how fantastic it is?
I spend quite some time in verifying that the CPP is handled within
LibTooling. I'm still not 100% sure, but I found strong indications that
it can deal with it - maybe even properly.
> In my reading a few months ago the LLVM/clang pretty printers sucked
> and there was no serious effort to make them better. (I could have
> misunderstood).
The problem seems to be the output writers rather than the internal
representation. The current Formatter is basically nothing but a
quick-and-dirty iterator over the internal representations. Even the
option-structs are currently simply hard-coded for GoogleStyle(), etc.
rather than accessible from outside.
> If the clang AST to source code pretty printer doesn't produce code
> that we can easily edit and manipulate then it isn't any good to us. It has
> to generate code pretty dang close to the code we have currently used to.
It has to produce exactly the code style we agree on ;-)
Why? Because we can access the internal representation. If we can't
achieve a full match, the description is incomplete.
Best regards,
Karli
>
> On Jan 21, 2013, at 10:10 PM, Karl Rupp <rupp at mcs.anl.gov> wrote:
>
>> Hi guys,
>>
>>>>>> Yes, though
>>>>>>
>>>>>> if (y < 12) {
>>>>>> ierr = Something();CHKERRQ(ierr);
>>>>>> }
>>>>>>
>>>>>> takes three times as many lines. I don't care much either way, but it's
>>>>>> nice to not waste vertical space.
>>>>>
>>>>> I agree here.
>>>>
>>>> I've prefered the 1 liners as well.
>>>
>>> So, am I the only one that like the uniformity of the three-liner?
>>
>> I think I'm currently on the best way towards a rabbit hole, with uncrustify
>> lacking the full understanding of the code an thus bound to failure. Rather
>> than tuning regular expressions and the like, I'll spend some time on
>> investigate further what Clang can do for us.
>>
>> First and foremost, it gives us access to the abstract syntax tree (AST),
>> see e.g.
>> http://clang.llvm.org/docs/IntroductionToTheClangAST.html
>> and already contains a formatter for Chromium-Style, Google-Style,
>> LLVM-Style. The formatter for multiple Languages is currently less than 2000
>> lines of code and eventually far more powerful than what we need.
>>
>> Via the C-interface LibClang
>> http://clang.llvm.org/doxygen/group__CINDEX.html
>> or LibTooling
>> http://clang.llvm.org/docs/LibTooling.html
>> it's much more natural to generate *the* PETSc-representation of code
>> irrespective of the input, and from the same AST generate e.g. the
>> Knepley-representation of code. At the same time, Clang remains an optional
>> dependency: One can work directly with the PETSc-representation without
>> Clang installed.
>>
>> Also, I found that they (Clang) are indeed aiming at a full code
>> documentation generator:
>> http://clang.llvm.org/OpenProjects.html
>> There is already a lot of parsing of Doxygen-style comments done in Clang
>> and accessible via the AST, so it's mostly missing output generators only.
>> It will take more time to reach maturity, though. It may, however, be just
>> what it needs to replace sowing in terms of Fortran stubs generation and
>> user manual generation.
>>
>> Best regards,
>> Karli
>>
>>
>>
>
