llvm dev - Aug 2021 - [cfe-dev] [RFC] Adding support for clang-format making further code modifying changes

On Tue, 10 Aug 2021, 12:10 Renato Golin via cfe-dev, <cfe-dev at
lists.llvm.org>
wrote:
> On Tue, 10 Aug 2021 at 09:32, MyDeveloper Day via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> I feel this is something that clang-format could be made to easily
>> handle. This RFC is about gaining a general consensus to let us try. We
>> feel we can add even more value.
>> Anyone who knows me, knows I'm very much pro "clang-format all
the things"
>>
>
> I agree with most of the sentiment in this thread, too. clang-format can
> be dangerous but it can also be so much more.
>
> I have been using clang-format on editors, pre-commit checks and ninja
> targets for a quite a while and I think it's a fundamental development
> tool. With it, style comments stop being a personal conversation and become
> tooling.
>
> I would like to see a world where there are no more long styling documents
> with personal angst in all projects, just a clang-format config file.
>
> I'm in favour of increasing the potency of clang-format. Quick checks
can
> be done on save, more expensive ones as ninja targets and even more
> expensive ones as CI.
>
> To me, the discussion of defaults and perils must be clear to all users
> and documentation may not be the best way: I've never read the
clang-format
> documentation.
>
> Another problem of clang-format is that there are so many options but not
> many people know enough of them.
>
> Yet another problem of clang-format is that its behaviour is different for
> the same options over different versions. We're stuck on
clang-format-9,
> not because it's "the best" but because re-formatting the
whole tree every
> time a new tool comes out is silly.
>
> So a good solution to all of these problems is to generate a default
> configuration file with all the options and comments on each one of them,
> including "this changes non-whitespace code", "this is quite
slow", "if
> this breaks code, here's how to fix", etc, and setting all of them
to the
> default value.
>
> We also nee to be able to update the config file with new options without
> destroying the old (often modified) ones, and make sure new versions only
> do new things if the config is different.
>
> I know, configuration management and backwards compatibility aren't
> trivial, but managing clang-format over time isn't either, and it
should.
> Well, it should, if it wants to be a catch-all tool to do all the things.
>
clang-format is designed to run on changed lines, not to have all code be
compliant. You can use it for the latter, but I think it's a pretty
fundamental difference in development goals.

> cheers,
> --renato
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210810/421726d5/attachment.html>

On Tue, Aug 10, 2021 at 13:13:09 +0200, Manuel Klimek via cfe-dev
wrote:
> clang-format is designed to run on changed lines, not to have all code be
> compliant. You can use it for the latter, but I think it's a pretty
> fundamental difference in development goals.
The problem I've seen is that the opinion of code formatted with 3 lines
of context can differ from 5 lines of context which can be still
different again given the entire file. The only reliable way we've
gotten it to work is to format the whole file every time. But we require
well-formatted code via CI processes, so that's fine (if one can afford
the "rewrite the world" every time the tool gets updated…hence why
some
projects are still on version 3.8(!), others 6, some even made it to 9).

--Ben