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
