Clang-format configuration discussion - pt 1

[Luca Fancellu <Luca.Fancellu@xxxxxxx>]

Hi all,

Let’s kick off the discussion about clang-format configuration, with this part 
1 I would like to discuss some configurable
that I feel are not controversial.

You can find the serie introducing clang-format here:
https://patchwork.kernel.org/project/xen-devel/cover/20231031132304.2573924-1-luca.fancellu@xxxxxxx/
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

--------------------------------------------------------------------------------------------------------------------------------------------------------------

ColumnLimit: 80

IndentWidth: 4

TabWidth: 4

UseTab: Never

---
Our coding style states it explicitly:
[...]
Indenting uses spaces, not tabs - in contrast to Linux. An indent
level consists of four spaces. Code within blocks is indented by one
extra indent level.
[...]

--------------------------------------------------------------------------------------------------------------------------------------------------------------

Language: Cpp

---
As the clang-format documentation says: Should be used for C, C++.

--------------------------------------------------------------------------------------------------------------------------------------------------------------

Standard: C++03

---
From the documentation: Parse and format C++ constructs compatible with this 
standard.

This value is used also in Linux.

--------------------------------------------------------------------------------------------------------------------------------------------------------------

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'

---
A vector of strings that should be interpreted as attributes/qualifiers instead 
of identifiers.
I’ve tried to list all the attributes I’ve found.

--------------------------------------------------------------------------------------------------------------------------------------------------------------

MacroBlockBegin: '^PLATFORM_START|^DT_DEVICE_START|^ACPI_DEVICE_START'

MacroBlockEnd: '^PLATFORM_END|^DT_DEVICE_END|^ACPI_DEVICE_END’

---
Regular expressions that matches begin and end of a block.
e.g.

PLATFORM_START(rcar2, "Renesas R-Car Gen2")
.compatible = rcar2_dt_compat,
.cpu_up = cpu_up_send_sgi,
.smp_init = rcar2_smp_init,
PLATFORM_END

--------------------------------------------------------------------------------------------------------------------------------------------------------------

StatementMacros:
  - 'PROGRESS'
  - 'PROGRESS_VCPU'
  - 'bitop'
  - 'guest_bitop'
  - 'testop'
  - 'guest_testop'
  - 'DEFINE_XEN_GUEST_HANDLE'
  - '__DEFINE_XEN_GUEST_HANDLE'
  - '___DEFINE_XEN_GUEST_HANDLE'
  - 'presmp_initcall'
  - '__initcall'
  - '__exitcall'

---
A vector of macros that should be interpreted as complete statements.
Typical macros are expressions, and require a semi-colon to be added; sometimes 
this is not the case, and this allows
to make clang-format aware of such cases.

While I was writing this, I’ve found that from ‘DEFINE_XEN_GUEST_HANDLE’ until 
the end of the list, probably I
shouldn’t list these entries because all of them end with semi-colon.

--------------------------------------------------------------------------------------------------------------------------------------------------------------

TypenameMacros:
  - 'XEN_GUEST_HANDLE'
  - 'XEN_GUEST_HANDLE_64'
  - 'XEN_GUEST_HANDLE_PARAM'
  - 'ELF_HANDLE_DECL'

---
A vector of macros that should be interpreted as type declarations instead of 
as function calls.
These are expected to be macros of the form:
STACK_OF(...)

--------------------------------------------------------------------------------------------------------------------------------------------------------------

WhitespaceSensitiveMacros:
  - '__stringify'

---
A vector of macros which are whitespace-sensitive and should not be touched.

--------------------------------------------------------------------------------------------------------------------------------------------------------------

Ok this is it for now, let me know your thoughts about them, ideally if I don’t 
get any reply in two weeks (22nd of November),
I will consider that we have an agreement on these configuration.

Cheers,
Luca