Message-ID: <CANiq72kqpcs==-+FOqoRwxHQ0s9D=gf-QAM9UTm4rA=GwHWUVQ@mail.gmail.com>
Date:   Fri, 4 Mar 2022 22:04:32 +0100
From:   Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To:     Joe Perches <joe@...ches.com>
Cc:     Tom Rix <trix@...hat.com>, Finn Thain <fthain@...ux-m68k.org>,
        Konrad Wilhelm Kleine <kkleine@...hat.com>,
        Bart Van Assche <bvanassche@....org>,
        kashyap.desai@...adcom.com, sumit.saxena@...adcom.com,
        shivasharan.srikanteshwara@...adcom.com, jejb@...ux.ibm.com,
        martin.petersen@...cle.com, Nathan Chancellor <nathan@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        megaraidlinux.pdl@...adcom.com, scsi <linux-scsi@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>, llvm@...ts.linux.dev
Subject: Re: [PATCH] scsi: megaraid: cleanup formatting of megaraid

On Fri, Mar 4, 2022 at 8:28 PM Joe Perches <joe@...ches.com> wrote:
>
> Is that statement really disputable?

By "Maybe", I only mean that you may be right (or not), i.e. we cannot
really show one way or the other with data.

But note that many people (including projects, companies and even
programming languages) prefer consistency and automated formatting vs.
the alternative.

> IYO.  I think using an SCCS with better language understanding rather
> than a line oriented one could be an improvement.  Such a tool could
> allow arbitrary style reformatting at check-in/check-out.

clang-format is not line oriented. In fact, you may be able to get
quite close to what you suggest with clang-format if you have a
project that is automatically formatted.

> All of these existing code are more human readable than the code
> reformatted using clang-format.

That is subjective (for some it may be good enough), and anyway you
compared it to the current config file (clang-format 4). The point I
raised is that clang-format 13 and future versions should be closer to
what you expect.

And by saying "I rather doubt clang-format will ever be 'close
enough'.", then there is little incentive for the clang-format team to
actually add support the things we need...

> I used whatever is the latest clang-format here with today's -next.
> https://releases.llvm.org/download.html

I think this may be the source of confusion -- even if you use
clang-format 13, you need to edit the config file to use the new
options.

In other words, when I said something is supported since e.g.
clang-format 9, one still needs to enable it in the config file.

> Then perhaps you as the maintainer of the kernel's .clang-format file
> could update the entries for those new options.

No, I cannot, because that is an error, thus breaks users of old
clang-format versions.

That is why I suggested to track the minimum LLVM supported version in
the kernel, i.e. go at least to LLVM 11. And then over time keep
upgrading it and getting better output.

> I believe the minimum clang version is already 11.  Maybe higher.
> I don't track clang or use it very much.  The clang version I use
> though is 13.

Yes, I am aware, please see above. The issue and why I did not "just
do it" is that people could have been using clang-format from e.g.
their distro, but compiling with GCC.

> But perhaps tweaking will just improve some cases and worsen others.

Yes, of course.

> I don't think so.

Why?

> There is no "one true editor".
> There will not be "one true source code formatter" either.

Not for every project, but for a single project, there can definitely
be a "single formatter". In fact, that is what many other projects do
in practice in order to reach a point where automatic formatting is
done.

Cheers,
Miguel

Powered by blists - more mailing lists