[cfe-dev] clang-format Style for RTEMS

[Mikail Yayla 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
<https://clang.llvm.org/doxygen/classclang_1_1Lexer.html#details>, but
where are characters inserted between the tokens (e.g. "\n") ?

Best,
Mikail




On Sat, Dec 29, 2018 at 10:20 PM Oleg Smolsky <oleg at cohesity.com> 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 <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> wrote:
>> >
>> > On Sat, Dec 15, 2018 at 12:40 AM Oleg Smolsky via cfe-dev <
>> 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
>> > 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/20190104/069fb8a1/attachment.html>