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

[Renato Golin via cfe-dev]

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.

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20210810/f89389b3/attachment.html>