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

[Manuel Klimek via llvm-dev]

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>