[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Clang-format configuration discussion - pt 1
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |