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@xxxxxxxxxxxxx> 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