clang-format Style for RTEMS

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

clang-format Style for RTEMS

Alexey Bataev via cfe-dev
Hello,

for the rtems (https://www.rtems.org/) source code we are trying to describe the rtems formatting style (https://devel.rtems.org/wiki/Developer/Coding/Conventions) using clang-format.
To see whether it can be done, we used ratemonperiod.c as an example and tried to set up a .clang-config file to describe the formatting.

In the mail I added the .clang configuration file and a ratemonperiodWKCustom_Commented.c, which is ratemonperiodOriginal.c with the configuration in .clang-config applied.

There are several problems in ratemonperiodWKCustom_Commented.c using clang-format.
Our questions are whether these points can be resolved using different configurations.
If they are not available with different configurations, we would like to ask you how much effort would be needed to implement the functionality which seems missing in clang-format:

The problems/needed functionality in ratemonperiodWKCustom_Commented.c:

1. In line 30-32, we can see that the "*" of the pointers are not aligned to the right. This is not supported yet it clang-format (see https://stackoverflow.com/questions/38392889/clang-format-align-asterisk-of-pointer-declaration-with-variable-name).

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.

5. Also in line 44, when a function call is split into multiple rows. The parameters can all be in separate rows, but clang-format always puts all the parameters in one row when they fit.

6. In line 80, clang-format does not stick to the column limit of 80. The line is 81 long. I have tried to configure a strict 80 column rule with the penalties, but there are still lines with 81 characters.

7. In line 127, I can't turn off the break after the function return type in this case.

8. In line 127, the parameter is not in a new line, but in rtems we would need every parameter of a function definition to always be in seperate line. Line 182, 279 have the same problem.

8. Lines 323, 330, 335, 348: It should be possible to specify that the functions arguments can be in seperate rows.

Best,
Mikail

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

ratemonperiodWKCustom_Commented.c (14K) Download Attachment
ratemonperiodOriginal.c (14K) Download Attachment
.clang-format (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: clang-format Style for RTEMS

Alexey Bataev via cfe-dev
On 2018-12-15 00:53, Mikail Yayla via cfe-dev wrote:

> Hello,
>
> for the rtems (https://www.rtems.org/) source code we are trying to
> describe the rtems formatting style
> (https://devel.rtems.org/wiki/Developer/Coding/Conventions) using
> clang-format.
> To see whether it can be done, we used ratemonperiod.c as an example
> and tried to set up a .clang-config file to describe the formatting.
>
> In the mail I added the .clang configuration file and a
> ratemonperiodWKCustom_Commented.c, which is ratemonperiodOriginal.c
> with the configuration in .clang-config applied.
>
> There are several problems in ratemonperiodWKCustom_Commented.c using
> clang-format.
> Our questions are whether these points can be resolved using different
> configurations.
> If they are not available with different configurations, we would like
> to ask you how much effort would be needed to implement the
> functionality which seems missing in clang-format:
>
> The problems/needed functionality in ratemonperiodWKCustom_Commented.c:
>
> 1. In line 30-32, we can see that the "*" of the pointers are not
> aligned to the right. This is not supported yet it clang-format (see
> https://stackoverflow.com/questions/38392889/clang-format-align-asterisk-of-pointer-declaration-with-variable-name).
>
Just set "PointerAlignment: Right". It works, I use it daily. However,
you will not get whitespace to align the parameters into columns. AFAIR
there is no such option.


> 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.

Or looking at it from the opposite direction - every one of us has
preferences that pertain to whitespace, yet the tool has a finite number
of options. From my experience it is much better to sacrifice a few
minor points and get automatic formatting across the entire team than
spend time writing/fixing/reviewing whitespace.

Oleg.

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: clang-format Style for RTEMS

Alexey Bataev via cfe-dev
On Sat, Dec 15, 2018 at 12:40 AM Oleg Smolsky via cfe-dev <[hidden email]> 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.

FWIW... --DD

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: clang-format Style for RTEMS

Alexey Bataev via cfe-dev
On Mon, Dec 17, 2018 at 3:11 PM Dominique Devienne via cfe-dev
<[hidden email]> wrote:

>
> On Sat, Dec 15, 2018 at 12:40 AM Oleg Smolsky via cfe-dev <[hidden email]> 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
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: clang-format Style for RTEMS

Alexey Bataev via cfe-dev
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 <[hidden email]> wrote:
On Mon, Dec 17, 2018 at 3:11 PM Dominique Devienne via cfe-dev
<[hidden email]> wrote:
>
> On Sat, Dec 15, 2018 at 12:40 AM Oleg Smolsky via cfe-dev <[hidden email]> 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
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: clang-format Style for RTEMS

Alexey Bataev 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 <[hidden email]> wrote:
On Mon, Dec 17, 2018 at 3:11 PM Dominique Devienne via cfe-dev
<[hidden email]> wrote:
>
> On Sat, Dec 15, 2018 at 12:40 AM Oleg Smolsky via cfe-dev <[hidden email]> 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
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: clang-format Style for RTEMS

Alexey Bataev via cfe-dev
Thank your for the pointers, I feel the FormatTest.cpp helped me in getting on the right track. Currently I'm trying to step through the code to get an understanding for it.

To me it looks like reformat(.), which is called in FormatTest.cpp (line 47), is a key function. Its definition is in Format.cpp (line 2151).
From here it is not clear to me where the "space" between the tokens is processed, I can only see that the code is passed as "StringRef Code", and then some replacement functions are called. In the documentation, it says the tokens are generated from the code with the lexer, but where are characters inserted between the tokens (e.g. "\n") ?

Best,
Mikail




On Sat, Dec 29, 2018 at 10:20 PM Oleg Smolsky <[hidden email]> wrote:

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 <[hidden email]> wrote:
On Mon, Dec 17, 2018 at 3:11 PM Dominique Devienne via cfe-dev
<[hidden email]> wrote:
>
> On Sat, Dec 15, 2018 at 12:40 AM Oleg Smolsky via cfe-dev <[hidden email]> 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
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: clang-format Style for RTEMS

Alexey Bataev via cfe-dev
In reply to this post by Alexey Bataev via cfe-dev
I can tell you I did in our smallish company I found best fitting
clang-format settings for our style to run on files, after
clang-formater is done I run sed. This gives 99% good formatting instead
of 90%.

Maybe instead of adding new switch per tweak one language as
regularexpresion is in my case can let user formatting possible, or just
run run sed afterwards.

Oto



>>>> 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev