[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <32f41b83-2019-475b-b72a-6b824fe796f8@digikod.net>
Date: Mon, 2 May 2022 12:29:41 +0200
From: Mickaël Salaün <mic@...ikod.net>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: Miguel Ojeda <ojeda@...nel.org>,
Andy Whitcroft <apw@...onical.com>,
Joe Perches <joe@...ches.com>,
Dwaipayan Ray <dwaipayanray1@...il.com>,
Lukas Bulwahn <lukas.bulwahn@...il.com>,
Nathan Chancellor <nathan@...nel.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Tom Rix <trix@...hat.com>, llvm@...ts.linux.dev,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: clang-format inconsistencies with checkpatch.pl
On 23/04/2022 18:14, Miguel Ojeda wrote:
> Hi Mickaël,
>
> On Sat, Apr 23, 2022 at 1:45 PM Mickaël Salaün <mic@...ikod.net> wrote:
>>
>> I also noticed that there is some clang-format configuration lines that
>> are commented because of incompatibilities with versions older than 6.
>> Shouldn't we require a minimal version, at least the 6th?
>
> I will be increasing this cycle the version to 11, which is the
> minimum LLVM supported at the moment, and then keep it sync'd to that
> minimum.
OK, thanks.
>
>> About checkpatch.pl, it incorrectly warns about space between function
>> name and open parenthesis for *for_each* functions (specifically
>> interpreted as "for" statements in .clang-format, e.g. list_for_each_entry).
>
> Note that the prevailing kernel style is to not have a space. This
> should be fixed with the increase to 11.
I was talking about the ForEachMacros exceptions. Should these be
removed or at least not updated for new for_each functions [1]?
[1] https://lore.kernel.org/r/20220412153906.428179-1-mic@digikod.net
Powered by blists - more mailing lists