[cfe-dev] clang-format Style for RTEMS

[Mikail Yayla 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 <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/20181229/1fe360b6/attachment.html>