[cfe-dev] clang-format Style for RTEMS

[Oleg Smolsky via cfe-dev]

Mikail, what you need to read is libformat:
     http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/

This code is responsible for formatting "unwrapped lines". It's not a 
full C++ parser, but it deals with tokens that are annotated with 
various bits of context-specific information. I think that the closing 
paren thing is quite easy to implement - you just force a line break on 
the token following the last function param. Controlling that however, 
will be a bit involved as you are essentially adding a user-visible 
option that is orthogonal to every existing formatting style. Getting 
consensus on that will be harder than making the source patch. Yet you 
can always maintain your own private patches...

Also, make sure to browse through the tests:
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/

The main file is FormatTest.cpp - it contains most of the C++ formatting 
tests, AFAIR.

Good luck,
Oleg.

On 2018-12-30 04:34, Mikail Yayla wrote:
> Thank you for the replies.
> I understand now that the principle of clang-format is to support a 
> limited number of styles well.
>
> We still would like to give a try in implementing some functionality, 
> to get a sense of how much work would be needed to adapt clang-format 
> for RTEMS.
>
> For RTEMS it would be good to have the option in C to put the ")" at 
> the end of a function declaration in a separate line, e.g.:
>
> bool _Thread_Initialize(
>    Thread_Information                   *information,
> [...]
>    Objects_Name                          name
> ) // <- in a new line
> {
>
> So far I've checked out and complied llvm and clang, and read some 
> articles in the clang documentation. The clang-format code is in 
> LLVM/build/tools/clang/tools/clang-format, and I can compile it as 
> well. I've been looking through the files and comments, but I'm 
> struggling to find the files or functions that would need changes to 
> implement the functionality.
> Could you please give me some pointers on how to proceed, what to 
> consider, or some reading material ?
>
> Best,
> Mikail
>
> On Mon, Dec 17, 2018 at 1:24 PM Roman Lebedev <lebedev.ri at gmail.com 
> <mailto:lebedev.ri at gmail.com>> wrote:
>
>     On Mon, Dec 17, 2018 at 3:11 PM Dominique Devienne via cfe-dev
>     <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>     >
>     > On Sat, Dec 15, 2018 at 12:40 AM Oleg Smolsky via cfe-dev
>     <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>     >>
>     >> > 2. In line 32, the ")" at the end of the parameter list needs
>     to be in
>     >> > a new row, but this doesn't seem to be supported in clang-format.
>     >> >
>     >> > 4. In line 44: If the function call is split into multiple
>     rows, the
>     >> > ");" should always be in a new row.
>     >> >
>     >> I don't believe there is an option to do that.
>     >>
>     >> Generally, the tool supports LLVM/Google/WebKit/Mozilla styles
>     fully and
>     >> there is a limited set of common/known tweaks that further
>     customize the
>     >> behavior. One can dream up any number of rules that pertain to
>     >> whitespace in different parts of the C++ syntax, but it would be an
>     >> uphill battle for you to get such changes into the code.
>     >
>     >
>     > Which is really disappointing from an OSS project...
>     >
>     > That a new language like Go forces a given style is OK,
>     > since their "one-true-format" existing from the beginning of the
>     language.
>     >
>     > But that clang-format rejects even the idea of a widely used
>     style of closing
>     > parens being on their own line, similar to how curlies are for
>     blocks, on code
>     > bases which have used those styles for decades, just because 3
>     large corporations
>     > use different styles, is a clear sign something's not right here.
>     >
>     > Options to support such a style were discussed several times on
>     this list, and I haven't
>     > been lurking for very long either, so it's not like this is a
>     one-off and seldom used style.
>     >
>     > Adopting clang-format on a codebase should strive for minimal
>     changes to well-formatted
>     > code using a given local style guide, minimising diffs at the
>     SCM level.
>     >
>     > It's also frankly a bit condescending to imply all those peoples
>     (and their millions of lines of code,
>     > quite literally) are using somehow a "wrong style" not "worthy"
>     of changing clang-format over.
>     >
>     > Oleg's reply is friendly and polite, no question there, but what
>     it implies is offending IMHO.
>
>     Have you seen
>     https://clang.llvm.org/docs/ClangFormatStyleOptions.html#adding-additional-style-options
>     ?
>     More options, while certainly allows for more customizability, is
>     always more code, tests,
>     behavior to preserve and account for going forward.
>
>     > FWIW... --DD
>
>     Roman.
>
>     > _______________________________________________
>     > cfe-dev mailing list
>     > cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>     > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181230/4b6423a4/attachment.html>