Re: [RFC PATCH v2 7/8] xen: Add clang-format configuration
> On 2 Nov 2023, at 11:53, Jan Beulich wrote: > > On 02.11.2023 12:41, Luca Fancellu wrote: >>> On 2 Nov 2023, at 09:10, Jan Beulich wrote: >>> On 31.10.2023 14:23, Luca Fancellu wrote: Add a clang format configuration for the Xen Hypervisor. Signed-off-by: Luca Fancellu --- xen/.clang-format | 693 ++ 1 file changed, 693 insertions(+) create mode 100644 xen/.clang-format >>> >>> I think this needs splitting and every setting then individually correlating >>> with what we have in ./CODING_STYLE. That would entail extending >>> ./CODING_STYLE >>> by anything not presently written down, but intended to be checked for. >> >> Do you mean introducing one parameter for each patch with the corresponding >> entry in >> CODING_STYLE? >> >> It would make sense, however there are 116 parameters, from those I think at >> least 56 needs >> to have a corresponding entry in CODING_STYLE (maybe in the end they will be >> less, but I don’t expect >> them to be less than 40), so given the amount of patches, I’m afraid to >> flood the mailing list. > > Some grouping may certainly make sense, for related settings. What I'm > completely lost with the present submission is which of the settings > merely enforce existing content of ./CODING_STYLE, and which ones > (silently) impose new rules which everyone may agree with, but also may > not. I will start a separate thread, referring to this serie, with all the maintainers and I will push a number of parameters at the time, starting from the one that already enforces the content of the coding style, with explanation for them. > >> I was thinking we could discuss them in chunks and update the serie during >> time, we could put in this >> patch also the update to the CODING_STYLE file. Something like the MISRA >> rule acceptance, what >> do you think? Shall we do the discussion by ML or by meetings? Every time I >> could bring up a number >> of parameters and update the serie when the discussion on them is finished. > > Afaic - email if at all possible. The more that, considering past > attempts to extend ./CODING_STYLE, for some items it may be close to > impossible to reach agreement. > >> This is my breakdown: >> >> 116 total configurables >> >> >> 13 straightforward > > What exactly do you qualify as such? > >> AttributeMacros: >> -[...] >> >> ColumnLimit: 80 >> >> IndentWidth: 4 >> >> Language: Cpp >> >> MacroBlockBegin: '^PLATFORM_START|^DT_DEVICE_START|^ACPI_DEVICE_START' >> >> MacroBlockEnd: '^PLATFORM_END|^DT_DEVICE_END|^ACPI_DEVICE_END' > > Without explanation it is, for example, not clear to me what these two > settings are about. Which includes me not understanding why these > identifiers are (apparently) special in some specific way. > >> Standard: C++03 > > I don't consider this "straightforward" at all. Only C99 could be deemed > straightforward here, imo. Sure, I will start from the “straightforward” which I mean the one that I think are less controversial, for example here I know well that we use C99, but clang-format was not really meant for C, it’s more Cpp oriented, however C++03 is the value used by Linux so I guess it can be fine also for us. Anyway as I said, I can start another thread with a few parameters that we can analyze each time. > >> >> 10 don't really need a discussion >> >> PenaltyBreakAssignment: 30 >> >> PenaltyBreakBeforeFirstCallParameter: 30 >> >> PenaltyBreakComment: 10 >> >> PenaltyBreakFirstLessLess: 0 >> >> PenaltyBreakOpenParenthesis: 100 >> >> PenaltyBreakString: 10 >> >> PenaltyExcessCharacter: 100 >> >> PenaltyIndentedWhitespace: 0 >> >> PenaltyReturnTypeOnItsOwnLine: 60 >> >> CommentPragmas: '^ IWYU pragma:' > > Like with the "straightforward" ones above, without knowing what these > affect (or whether some simply don't affect us at all, and hence could > be set to any value) I can't follow the "don't really need a discussion" > qualification. So here I meant that these parameters are only tuning the algorithm, so their value is not something enforcing a rule, so they are in some way “bending” some of them but their effect is visible mostly in conjunction with the overall computation of every rule. But of course we are going to discuss also them, it’s just that I don’t feel there might be disagreements on them. > > Jan
Re: [RFC PATCH v2 7/8] xen: Add clang-format configuration
On 02.11.2023 12:41, Luca Fancellu wrote: >> On 2 Nov 2023, at 09:10, Jan Beulich wrote: >> On 31.10.2023 14:23, Luca Fancellu wrote: >>> Add a clang format configuration for the Xen Hypervisor. >>> >>> Signed-off-by: Luca Fancellu >>> --- >>> xen/.clang-format | 693 ++ >>> 1 file changed, 693 insertions(+) >>> create mode 100644 xen/.clang-format >> >> I think this needs splitting and every setting then individually correlating >> with what we have in ./CODING_STYLE. That would entail extending >> ./CODING_STYLE >> by anything not presently written down, but intended to be checked for. > > Do you mean introducing one parameter for each patch with the corresponding > entry in > CODING_STYLE? > > It would make sense, however there are 116 parameters, from those I think at > least 56 needs > to have a corresponding entry in CODING_STYLE (maybe in the end they will be > less, but I don’t expect > them to be less than 40), so given the amount of patches, I’m afraid to flood > the mailing list. Some grouping may certainly make sense, for related settings. What I'm completely lost with the present submission is which of the settings merely enforce existing content of ./CODING_STYLE, and which ones (silently) impose new rules which everyone may agree with, but also may not. > I was thinking we could discuss them in chunks and update the serie during > time, we could put in this > patch also the update to the CODING_STYLE file. Something like the MISRA rule > acceptance, what > do you think? Shall we do the discussion by ML or by meetings? Every time I > could bring up a number > of parameters and update the serie when the discussion on them is finished. Afaic - email if at all possible. The more that, considering past attempts to extend ./CODING_STYLE, for some items it may be close to impossible to reach agreement. > This is my breakdown: > > 116 total configurables > > > 13 straightforward What exactly do you qualify as such? > AttributeMacros: > -[...] > > ColumnLimit: 80 > > IndentWidth: 4 > > Language: Cpp > > MacroBlockBegin: '^PLATFORM_START|^DT_DEVICE_START|^ACPI_DEVICE_START' > > MacroBlockEnd: '^PLATFORM_END|^DT_DEVICE_END|^ACPI_DEVICE_END' Without explanation it is, for example, not clear to me what these two settings are about. Which includes me not understanding why these identifiers are (apparently) special in some specific way. > Standard: C++03 I don't consider this "straightforward" at all. Only C99 could be deemed straightforward here, imo. > > 10 don't really need a discussion > > PenaltyBreakAssignment: 30 > > PenaltyBreakBeforeFirstCallParameter: 30 > > PenaltyBreakComment: 10 > > PenaltyBreakFirstLessLess: 0 > > PenaltyBreakOpenParenthesis: 100 > > PenaltyBreakString: 10 > > PenaltyExcessCharacter: 100 > > PenaltyIndentedWhitespace: 0 > > PenaltyReturnTypeOnItsOwnLine: 60 > > CommentPragmas: '^ IWYU pragma:' Like with the "straightforward" ones above, without knowing what these affect (or whether some simply don't affect us at all, and hence could be set to any value) I can't follow the "don't really need a discussion" qualification. Jan
Re: [RFC PATCH v2 7/8] xen: Add clang-format configuration
Hi Jan, > On 2 Nov 2023, at 09:10, Jan Beulich wrote: > > On 31.10.2023 14:23, Luca Fancellu wrote: >> Add a clang format configuration for the Xen Hypervisor. >> >> Signed-off-by: Luca Fancellu >> --- >> xen/.clang-format | 693 ++ >> 1 file changed, 693 insertions(+) >> create mode 100644 xen/.clang-format > > I think this needs splitting and every setting then individually correlating > with what we have in ./CODING_STYLE. That would entail extending > ./CODING_STYLE > by anything not presently written down, but intended to be checked for. Do you mean introducing one parameter for each patch with the corresponding entry in CODING_STYLE? It would make sense, however there are 116 parameters, from those I think at least 56 needs to have a corresponding entry in CODING_STYLE (maybe in the end they will be less, but I don’t expect them to be less than 40), so given the amount of patches, I’m afraid to flood the mailing list. I was thinking we could discuss them in chunks and update the serie during time, we could put in this patch also the update to the CODING_STYLE file. Something like the MISRA rule acceptance, what do you think? Shall we do the discussion by ML or by meetings? Every time I could bring up a number of parameters and update the serie when the discussion on them is finished. This is my breakdown: 116 total configurables 13 straightforward AttributeMacros: -[...] ColumnLimit: 80 IndentWidth: 4 Language: Cpp MacroBlockBegin: '^PLATFORM_START|^DT_DEVICE_START|^ACPI_DEVICE_START' MacroBlockEnd: '^PLATFORM_END|^DT_DEVICE_END|^ACPI_DEVICE_END' Standard: C++03 StatementMacros: - [...] TabWidth: 4 TypenameMacros: - 'XEN_GUEST_HANDLE' - 'XEN_GUEST_HANDLE_64' - 'XEN_GUEST_HANDLE_PARAM' - 'ELF_HANDLE_DECL' UseTab: Never WhitespaceSensitiveMacros: - '__stringify' 56 that requires discussions QualifierAlignment: Custom QualifierOrder: ['static', 'inline', 'const', 'volatile', 'type'] AlignAfterOpenBracket: Align AlignArrayOfStructures: Left AlignConsecutiveAssignments: Enabled: false AcrossEmptyLines: false AcrossComments: false AlignConsecutiveBitFields: None AlignConsecutiveDeclarations: None AlignConsecutiveMacros: Enabled: false AcrossEmptyLines: false AcrossComments: false AlignEscapedNewlines: Right AlignOperands: Align AlignTrailingComments: false AllowAllArgumentsOnNextLine: false AllowAllParametersOfDeclarationOnNextLine: false AllowShortBlocksOnASingleLine: Never AllowShortCaseLabelsOnASingleLine: false AllowShortFunctionsOnASingleLine: None AllowShortIfStatementsOnASingleLine: Never AllowShortLoopsOnASingleLine: false AlwaysBreakAfterReturnType: None AlwaysBreakBeforeMultilineStrings: false BinPackArguments: true BinPackParameters: true BitFieldColonSpacing: None BreakBeforeBraces: Custom BraceWrapping: AfterCaseLabel: true AfterFunction: true BeforeElse: true AfterExternBlock: true AfterEnum: false AfterStruct: false AfterUnion: false AfterControlStatement: Always BeforeWhile: false IndentBraces: false SplitEmptyFunction: false AfterClass: false AfterNamespace: false AfterObjCDeclaration: false BeforeCatch: false BeforeLambdaBody: false SplitEmptyRecord: true SplitEmptyNamespace: true BreakBeforeBinaryOperators: None BreakBeforeTernaryOperators: true BreakStringLiterals: false IncludeBlocks: Preserve IndentCaseBlocks: false IndentCaseLabels: false IndentGotoLabels: true IndentPPDirectives: None IndentWrappedFunctionNames: false InsertBraces: false KeepEmptyLinesAtTheStartOfBlocks: false MaxEmptyLinesToKeep: 1 PointerAlignment: Right PPIndentWidth: -1 ReflowComments: false SeparateDefinitionBlocks: Always SortIncludes: Never SpaceAfterCStyleCast: false SpaceAfterLogicalNot: false SpaceAroundPointerQualifiers: After SpaceBeforeAssignmentOperators: true SpaceBeforeCaseColon: false SpaceBeforeParens: ControlStatementsExceptForEachMacros SpaceBeforeSquareBrackets: false SpaceInEmptyParentheses: false SpacesBeforeTrailingComments: 1 SpacesInConditionalStatement: true SpacesInCStyleCastParentheses: false SpaceInEmptyBlock: false SpacesInLineCommentPrefix: Minimum: 1 Maximum: -1 SpacesInParentheses: false SpacesInSquareBrackets: false 10 don't really need a discussion PenaltyBreakAssignment: 30 PenaltyBreakBeforeFirstCallParameter: 30 PenaltyBreakComment: 10 PenaltyBreakFirstLessLess: 0 PenaltyBreakOpenParenthesis: 100 PenaltyBreakString: 10 PenaltyExcessCharacter: 100 PenaltyIndentedWhitespace: 0 PenaltyReturnTypeOnItsOwnLine: 60 CommentPragmas: '^ IWYU pragma:' 37 non
Re: [RFC PATCH v2 7/8] xen: Add clang-format configuration
On 31.10.2023 14:23, Luca Fancellu wrote:
> Add a clang format configuration for the Xen Hypervisor.
>
> Signed-off-by: Luca Fancellu
> ---
> xen/.clang-format | 693 ++
> 1 file changed, 693 insertions(+)
> create mode 100644 xen/.clang-format
I think this needs splitting and every setting then individually correlating
with what we have in ./CODING_STYLE. That would entail extending ./CODING_STYLE
by anything not presently written down, but intended to be checked for. Merely
...
> --- /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
... pointing to further doc is helpful in general, but imo insufficient for
the introduction of the various settings.
Jan
> +#
> +---
> +
> +# [not specified]
> +# Align function parameter that goes into a new line, under the open bracket
> +# (supported in clang-format 3.8)
> +AlignAfterOpenBracket: Align
> +
> +# [not specified]
> +# Align array of struct's elements by column and justify
> +# struct test demo[] =
> +# {
> +# {56, 23,"hello"},
> +# {-1, 93463, "world"},
> +# {7, 5, "!!" }
> +# };
> +# (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
> +
> +# [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
> +
> +# [not specified]
> +# Align escaped newlines to the right (supported in clang-format 5)
> +AlignEscapedNewlines: Right
> +
> +# [not specified]
> +# Aligns operands of a single expression that needs to be split over multiple
> +# lines (supported in clang-format 3.5)
> +AlignOperands: Align
> +
> +# Do not align trailing consecutive comments (It helps to make clang-format
> +# reproduce the same output when it runs on an already formatted file)
> +# (supported in clang-format 3.7)
> +AlignTrailingComments: false
> +
> +# [not specified]
> +# Do not put all function call arguments on a new line, try to have at least
> +# the first one close to the opening parenthesis (supported in clang-format
> 9)
> +AllowAllArgumentsOnNextLine: false
> +
> +# [not specified]
> +# Do not put all function declaration parameters on a new line, try to have
> at
> +# least the first one close to the opening parenthesis
> +# (supported in clang-format 3.3)
> +AllowAllParametersOfDeclarationOnNextLine: false
> +
> +# Bracing condition needs to be respected even if the line is so short that
> the
> +# final block brace can stay on a single line
> +# (supported in clang-format 3.5)
> +AllowShortBlocksOnASingleLine: Never
> +
> +# (supported in clang-format 3.6)
> +AllowShortCaseLabelsOnASingleLine: false
> +
> +# (supported in clang-format 3.5)
> +AllowShortFunctionsOnASingleLine: None
> +
> +# (supported in clang-format 3.3)
> +AllowShortIfStatementsOnASingleLine: Never
> +
> +# (supported in clang-format 3.7)
> +AllowShortLoopsOnASingleLine: false
> +
> +# [not specified]
> +# Do not add a break after the definition return type
> +# (supported in clang-format 3.8)
> +AlwaysBreakAfterReturnType: None
> +
> +# [not specified]
> +# There is no need to use a break after an assigment to a multiline string
> +# (supported in clang-format 3.4)
> +AlwaysBreakBeforeMultilineStrings: false
> +
> +# (supported in clang-format 3.4)
> +AlwaysBreakTemplateDeclarations: false
> +
> +# Specify Xen's macro attributes (supported in clang-format 12)
> +AttributeMacros:
> + - '__init'
> + - '__exit'
> + - '__initdata'
> + - '__initconst'
> + - '__initconstrel'
> + - '__initdata_cf_clobber'
> + - '__initconst_cf_clobber'
> + - '__hwdom_init'
> + - '__hwdom_initdata'
> + - '__maybe_unused'
> + - '__packed'
> + - '__stdcall'
> + - '__vfp_aligned'
> + - '__alt_call_maybe_initdata'
> + - '__cacheline_aligned'
> + - '__ro_after_init'
> + - 'always_inline'
> + - 'noinline'
> + - 'noreturn'
> + - '__weak'
> + - '__inline__'
> + - '__attribute_const__'
> + - '__transparent__'
> + - '__used'
> + - '__must_check'
> + - '__kprobes'
> +
> +# [not specified]
> +# Try always to pack function call arguments on the same line before breaking
> +# (supported in clang-format
[RFC PATCH v2 7/8] xen: Add clang-format configuration
Add a clang format configuration for the Xen Hypervisor.
Signed-off-by: Luca Fancellu
---
xen/.clang-format | 693 ++
1 file changed, 693 insertions(+)
create mode 100644 xen/.clang-format
diff --git a/xen/.clang-format b/xen/.clang-format
new file mode 100644
index ..7880709fe1fd
--- /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
+
+# [not specified]
+# Align array of struct's elements by column and justify
+# struct test demo[] =
+# {
+# {56, 23,"hello"},
+# {-1, 93463, "world"},
+# {7, 5, "!!" }
+# };
+# (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
+
+# [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
+
+# [not specified]
+# Align escaped newlines to the right (supported in clang-format 5)
+AlignEscapedNewlines: Right
+
+# [not specified]
+# Aligns operands of a single expression that needs to be split over multiple
+# lines (supported in clang-format 3.5)
+AlignOperands: Align
+
+# Do not align trailing consecutive comments (It helps to make clang-format
+# reproduce the same output when it runs on an already formatted file)
+# (supported in clang-format 3.7)
+AlignTrailingComments: false
+
+# [not specified]
+# Do not put all function call arguments on a new line, try to have at least
+# the first one close to the opening parenthesis (supported in clang-format 9)
+AllowAllArgumentsOnNextLine: false
+
+# [not specified]
+# Do not put all function declaration parameters on a new line, try to have at
+# least the first one close to the opening parenthesis
+# (supported in clang-format 3.3)
+AllowAllParametersOfDeclarationOnNextLine: false
+
+# Bracing condition needs to be respected even if the line is so short that the
+# final block brace can stay on a single line
+# (supported in clang-format 3.5)
+AllowShortBlocksOnASingleLine: Never
+
+# (supported in clang-format 3.6)
+AllowShortCaseLabelsOnASingleLine: false
+
+# (supported in clang-format 3.5)
+AllowShortFunctionsOnASingleLine: None
+
+# (supported in clang-format 3.3)
+AllowShortIfStatementsOnASingleLine: Never
+
+# (supported in clang-format 3.7)
+AllowShortLoopsOnASingleLine: false
+
+# [not specified]
+# Do not add a break after the definition return type
+# (supported in clang-format 3.8)
+AlwaysBreakAfterReturnType: None
+
+# [not specified]
+# There is no need to use a break after an assigment to a multiline string
+# (supported in clang-format 3.4)
+AlwaysBreakBeforeMultilineStrings: false
+
+# (supported in clang-format 3.4)
+AlwaysBreakTemplateDeclarations: false
+
+# Specify Xen's macro attributes (supported in clang-format 12)
+AttributeMacros:
+ - '__init'
+ - '__exit'
+ - '__initdata'
+ - '__initconst'
+ - '__initconstrel'
+ - '__initdata_cf_clobber'
+ - '__initconst_cf_clobber'
+ - '__hwdom_init'
+ - '__hwdom_initdata'
+ - '__maybe_unused'
+ - '__packed'
+ - '__stdcall'
+ - '__vfp_aligned'
+ - '__alt_call_maybe_initdata'
+ - '__cacheline_aligned'
+ - '__ro_after_init'
+ - 'always_inline'
+ - 'noinline'
+ - 'noreturn'
+ - '__weak'
+ - '__inline__'
+ - '__attribute_const__'
+ - '__transparent__'
+ - '__used'
+ - '__must_check'
+ - '__kprobes'
+
+# [not specified]
+# Try always to pack function call arguments on the same line before breaking
+# (supported in clang-format 3.7)
+BinPackArguments: true
+
+# [not specified]
+# Try always to pack function declaration parameters on the same line before
+# breaking (supported in clang-format 3.7)
+BinPackParameters: true
+
+# [not specified]
+# Do not add a spaces on bitfield 'unsigned bf:2;'
+# (supported in clang-format 12)
+BitFieldColonSpacing: None
+
+# Xen's coding style does not follow clang-format already available profiles
for
+# breaking before braces, so set it to Custom and specify each case separately
+# (supported in clang-format 3.8)
+BraceWrapping:
+ # Braces ('{' and '}') are usually placed on a line of their
