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:
-
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).
-
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.
-
In line 44: If the function call is split into multiple rows, the “);” should always be in a new row.
-
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.
-
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.
-
In line 127, I can’t turn off the break after the function return type in this case.
-
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.
-
Lines 323, 330, 335, 348: It should be possible to specify that the functions arguments can be in seperate rows.
Best,
Mikail
ratemonperiodWKCustom_Commented.c (10.8 KB)
ratemonperiodOriginal.c (10.3 KB)
.clang-format (3.2 KB)
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 clang-format: Align asterisk (*) of pointer declaration with variable name - Stack Overflow).
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.
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
> 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 Clang-Format Style Options — Clang 18.0.0git documentation
?
More options, while certainly allows for more customizability, is
always more code, tests,
behavior to preserve and account for going forward.
FWIW... --DD
Roman.
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
Mikail, what you need to read is libformat:
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:
The main file is FormatTest.cpp - it contains most of the C++ formatting tests, AFAIR.
Good luck,
Oleg.
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