[cfe-dev] Design: clang-format

Manuel Klimek klimek at google.com
Mon May 14 01:09:50 PDT 2012


On Mon, May 14, 2012 at 3:08 AM, Gregory Szorc <gregory.szorc at gmail.com>wrote:

> On 5/11/12 9:27 AM, Manuel Klimek wrote:
> > Hi,
> >
> > we're working on the design of clang-format; there are quite a few open
> > questions, but I'd rather get some early feedback to see whether we're
> > completely off track somewhere.
>
> I'm glad to see work in this area!
>
> A few months ago, I set out to accomplish something similar. I didn't
> make much progress because I wanted to utilize the Python bindings
> instead of writing C++ (mainly because I think tools like this are much
> easier to implement in higher-level languages). Anyway, I was
>

I think you're targeting something different here (worth pursuing, for
sure, but different).

clang-format is a tool to reformat code. The main use case we have is to
reformat code after a refactoring. Our main goal is to write refactoring
tools & services. That's also why it must be implemented in C++ - we want
to be able to combine refactorings and the clean-up in one process and
output only changes.

Now the second level above this is what I call a "linter-style" tool. This
might well be better implemented in python on top of a query API (I doubt
it, but I might be wrong). That seems more what you're trying to build. I
want to see such a tool, too, but we won't get that as one of our
priorities any time soon (I know an engineer who would be interested in
contributing, but he won't have enough time to do the design work).

I'd suggest before going too far down a path here, to write up a short
design idea, and send it past  this list, so you can get feedback by people
who understand the implications of the different approaches very well and
can catch dead ends before we hit them...

Cheers,
/Manuel


> sidetracked because the Python bindings were lacking features needed to
> implement such a tool. (This actually spawned much of my work on the
> Python bindings, which have been trickling into the tree.)
>
> Anyway, you may be interested in clanalyze [1]. My goal for clanalyze
> was to build APIs for inspecting the lexer output and AST. It is
> essentially a higher-level API for the Python bindings. I didn't get
> very far, so the code isn't that useful. What I do think is worth
> considering is the concept of an API that sits above the lexer output
> and AST that provides commonly-needed functionality. I think any tool
> that does code formatting, style critiquing, documentation generation,
> etc, is bound to perform many of the same tasks. e.g. "get a list of all
> the functions in a class," "list all the classes declared in this file,"
> "return the comment block(s) before this declaration."
>
> Since something like clang-format would need such abilities and since
> there are many other tools that could reuse this logic, I think there is
> value in implementing a higher-level "query" interface as a standalone
> library/module. Such an interface could also provide a bridge between
> the lexer tokens and AST (you need to use both for things like getting
> the comment block(s) before a declaration).
>
> I didn't get very far with clanalyze (yet). Hopefully you can do better.
>
> Also worth mentioning is linty [2].
>
> Greg
>
> [1] https://github.com/indygreg/clanalyze
> [2] https://github.com/holtgrewe/linty
>
> _______________________________________________
> 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/20120514/ecd98b37/attachment.html>


More information about the cfe-dev mailing list