> On 27 Nov 2023, at 15:13, Jan Beulich <jbeul...@suse.com> wrote:
>
> On 27.11.2023 15:58, Luca Fancellu wrote:
>>> On 27 Nov 2023, at 12:20, Jan Beulich <jbeul...@suse.com> wrote:
>>> On 24.11.2023 15:52, Luca Fancellu wrote:
>>>>> On 24 Nov 2023, at 12:47, Jan Beulich <jbeul...@suse.com> wrote:
>>>>> On 23.11.2023 15:47, Luca Fancellu wrote:
>>>>>> Let’s continue the discussion about clang-format configuration, this is
>>>>>> part 2, previous discussions are:
>>>>>>
>>>>>> -
>>>>>> https://lists.xenproject.org/archives/html/xen-devel/2023-11/msg00498.html
>>>>>>
>>>>>> You can find the serie introducing clang-format here:
>>>>>> https://patchwork.kernel.org/project/xen-devel/cover/20231031132304.2573924-1-luca.fance...@arm.com/
>>>>>> and there is also a patch linked to my gitlab account where you can find
>>>>>> the output for the hypervisor code.
>>>>>>
>>>>>> For a full list of configurables and to find the possible values for
>>>>>> them, please refer to this page:
>>>>>> https://clang.llvm.org/docs/ClangFormatStyleOptions.html
>>>>>>
>>>>>> --------------------------------------------------------------------------------------------------------------------------------------------------
>>>>>>
>>>>>> Our coding style doesn’t mention anything about alignment, shall we add
>>>>>> a new section?
>>>>>> I can send patches when we reach agreement on each of these rules.
>>>>>>
>>>>>>
>>>>>> QualifierAlignment: Custom
>>>>>> QualifierOrder: ['static', 'inline', 'const', 'volatile', 'type']
>>>>>>
>>>>>> ---
>>>>>> For “QualifierAlignment” I chose Custom in order to apply in
>>>>>> “QualifierOrder” an order for the
>>>>>> qualifiers that match the current codebase, we could specify also
>>>>>> “Leave” in order to keep
>>>>>> them as they are.
>>>>>
>>>>> Where do attributes go in this sequence?
>>>>
>>>> I think function declaration/definition and variables.
>>>
>>> How does this relate to my question? I asked about the sequence of elements
>>> listed for QualifierOrder:, where attributes don't appear at all right now.
>>
>> Sorry, I misread your question, attributes are like invisible for the tool,
>> they can be placed wherever between
>> each of the QualifierOrder items.
>
> Hoho, one thing where various options are tolerated.
>
>>>>>> --------------------------------------------------------------------------------------------------------------------------------------------------
>>>>>>
>>>>>> AlignAfterOpenBracket: Align
>>>>>>
>>>>>> ---
>>>>>> This one is to align function parameters that overflows the line length,
>>>>>> I chose to align them
>>>>>> to the open bracket to match the current codebase (hopefully)
>>>>>>
>>>>>> e.g.:
>>>>>> someLongFunction(argument1,
>>>>>> argument2);
>>>>>
>>>>> The above matches neither of the two generally permitted styles:
>>>>>
>>>>> someLongFunction(argument1,
>>>>> argument2);
>>>>>
>>>>> someLongFunction(
>>>>> argument1,
>>>>> argument2);
>>>>>
>>>>> Then again from its name I would infer this isn't just about function
>>>>> arguments?
>>>>
>>>> I think it applies to parameters and arguments of functions and macro,
>>>> given the description in the docs.
>>>>
>>>> I see your two snippets above but I’ve always found at least on arm a
>>>> predominance of
>>>> the style above for functions, so arguments aligned after the opening
>>>> bracket, for macros
>>>> there is a mix.
>>>
>>> The latter "above" refers to which form exactly? The one you originally
>>> spelled out, or the former of what my reply had?
>>
>> In my reply I was referring to the one I originally spelled out.
>
> But that's properly malformed, for not aligning argument2 with argument1.
> Where are such constructs commonly used? I just took one example (cpuerrata.c)
> and only found my first form of wrapping.
I had to go back to the thread to realise there was some style issue, the
snippet I thought
I sent already had argument2 aligned under argument1, like this:
e.g.:
someLongFunction(argument1,
argument2);
Even my wording was not really accurate, as I meant:
“This one is to align function parameters that overflows the line length, I
chose to align them
*after* the open bracket to match the current codebase (hopefully)”
So to summarize, this value formats the code to have overflowing args/param
aligned after
the open braket.
But I understand that having only one format is not desirable.
>
> Jan
>
