[RFC] .clang-format: avoid call wrapping that triggers OPEN_ENDED_LINE

[RFC] .clang-format: avoid call wrapping that triggers OPEN_ENDED_LINE

[Ralf Lici]

Hi,

while looking at .clang-format output in the kernel tree, I ran into a
recurring case where long function calls are reformatted by breaking
immediately after the opening parenthesis of the call.

A representative example is this:

Original code:
int __skb_unclone_keeptruesize(struct sk_buff *skb, gfp_t pri)
{
	...
	if (...) {
		pr_err_once("__skb_unclone_keeptruesize() skb_end_offset() %u -> %u\n",
			    saved_end_offset, skb_end_offset(skb));
	}
	...
}

Formatted with the current kernel .clang-format:
int __skb_unclone_keeptruesize(struct sk_buff *skb, gfp_t pri)
{
	...
	if (...) {
		pr_err_once(
			"__skb_unclone_keeptruesize() skb_end_offset() %u -> %u\n",
			saved_end_offset, skb_end_offset(skb));
	...
}

The reformatted version looks less desirable for this kind of kernel
call site, and it conflicts with checkpatch's OPEN_ENDED_LINE check for
for added lines ending in '[' or '('.

I tried to understand whether this could be improved while staying
within the current .clang-format baseline. The closest existing knob
seems to be PenaltyBreakBeforeFirstCallParameter, but in my testing it
does not appear to provide a clean or convincing solution: the value
needed to preserve the original layout in the example above is very
high, which makes it look more like a blunt global workaround than a
principled fix.

The more promising option seems to be PenaltyBreakOpenParenthesis, which
is a much more direct control for this behavior. However, that option is
only available in newer clang-format versions (starting from v14), so
using it would mean revisiting the current version expectations for the
in-tree .clang-format, which is clang-format 11 or newer.

Therefore I wanted to ask whether maintainers think this class of
formatting is worth addressing at all, and if so, whether there is any
openness to adjusting the existing cost model while keeping the current
clang-format compatibility expectations, or revisiting the minimum
supported clang-format version for .clang-format so that more specific
options can be used.

Thanks,

-- 
Ralf Lici
Mandelbit Srl

Re: [RFC] .clang-format: avoid call wrapping that triggers OPEN_ENDED_LINE

[Miguel Ojeda]

On Mon, Mar 16, 2026 at 9:29 AM Ralf Lici <ralf@mandelbit.com> wrote:
>
> Therefore I wanted to ask whether maintainers think this class of
> formatting is worth addressing at all, and if so, whether there is any
> openness to adjusting the existing cost model while keeping the current
> clang-format compatibility expectations, or revisiting the minimum
> supported clang-format version for .clang-format so that more specific
> options can be used.

Yeah, we can definitely use options up to the usual LLVM minimum
(currently 15), and yeah, we can tweak things since `clang-format` is
opt-in.

Some maintainers already use `clang-format` to format full files, so
we should be mindful of big changes; but if they are worth it, the
sooner we do it, the better.

Thanks!

Cheers,
Miguel

Re: [RFC] .clang-format: avoid call wrapping that triggers OPEN_ENDED_LINE

[Ralf Lici]

On 3/22/26 12:06, Miguel Ojeda wrote:
> On Mon, Mar 16, 2026 at 9:29 AM Ralf Lici <ralf@mandelbit.com> wrote:
>>
>> Therefore I wanted to ask whether maintainers think this class of
>> formatting is worth addressing at all, and if so, whether there is any
>> openness to adjusting the existing cost model while keeping the current
>> clang-format compatibility expectations, or revisiting the minimum
>> supported clang-format version for .clang-format so that more specific
>> options can be used.
> 
> Yeah, we can definitely use options up to the usual LLVM minimum
> (currently 15), and yeah, we can tweak things since `clang-format` is
> opt-in.
> 
> Some maintainers already use `clang-format` to format full files, so
> we should be mindful of big changes; but if they are worth it, the
> sooner we do it, the better.

I tested PenaltyBreakOpenParenthesis across a few representative files,
varying the value and counting lines ending with '(' after formatting.
The results show that the value needed to suppress open-paren breaks
varies widely across files, from a few hundred (e.g. net/core/skbuff.c)
to tens of thousands (e.g. fs/ext4/super.c).

The issue is not just the scale of the option value: constructs like
TP_STRUCT__entry( use the open-paren break intentionally, as part of
their formatting structure. A global penalty cannot distinguish between
those and the cases this RFC was originally motivated by.

Therefore I will drop this approach for now, unless someone has ideas
for a more targeted solution. Sorry for the extra churn, and thanks for
the feedback.

Cheers,

-- 
Ralf Lici
Mandelbit Srl