Re: [RFC PATCH 5/5] xen: Add clang-format configuration

[Jan Beulich <jbeulich@xxxxxxxx>]

On 28.07.2023 10:11, Luca Fancellu wrote:
> --- /dev/null
> +++ b/xen/.clang-format
> @@ -0,0 +1,693 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# clang-format configuration file. Intended for clang-format >= 15.
> +#
> +# For more information, see:
> +#
> +#   Documentation/process/clang-format.rst
> +#   https://clang.llvm.org/docs/ClangFormat.html
> +#   https://clang.llvm.org/docs/ClangFormatStyleOptions.html
> +#
> +---
> +
> +# [not specified]
> +# Align function parameter that goes into a new line, under the open bracket
> +# (supported in clang-format 3.8)
> +AlignAfterOpenBracket: Align

I'm not convinced this rule (assuming I'm getting it right) is
suitable in all cases, especially for functions with long names or
very many parameters.

> +# [not specified]
> +# Align array of struct's elements by column and justify
> +# struct test demo[] =
> +# {
> +#     {56, 23,    "hello"},
> +#     {-1, 93463, "world"},
> +#     {7,  5,     "!!"   }
> +# };

I'm pretty sure we want to have blanks immediately inside the braces.

> +# (supported in clang-format 13)
> +AlignArrayOfStructures: Left
> +
> +# [not specified]
> +# Align consecutive assignments (supported in clang-format 3.8)
> +AlignConsecutiveAssignments:
> +  Enabled: true
> +  AcrossEmptyLines: true
> +  AcrossComments: false

This is something we want to permit, but not demand, I think. I'm also
unconvinced we want it across empty lines.

> +# [not specified]
> +# Do not align consecutive bit fields (supported in clang-format 11)
> +AlignConsecutiveBitFields: None
> +
> +# [not specified]
> +# Do not align values of consecutive declarations
> +# (supported in clang-format 3.8)
> +AlignConsecutiveDeclarations: None
> +
> +# [not specified]
> +# Align values of consecutive macros (supported in clang-format 9)
> +AlignConsecutiveMacros:
> +  Enabled: true
> +  AcrossEmptyLines: true
> +  AcrossComments: true

This also looks to aggressive to me.

And I guess I'll stop here. What is the plan wrt discussing which
aspects we want to require and which we want to permit but not
require? Or is there alternatively a way to leave unconfigured
(and hence unaltered) anything that's not already spelled out in
./CODING_STYLE?

Jan