Re: Clang-format configuration discussion - pt 1

[Luca Fancellu <Luca.Fancellu@xxxxxxx>]

> On 13 Nov 2023, at 11:31, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> 
> On 08.11.2023 10:53, Luca Fancellu wrote:
> --------------------------------------------------------------------------------------------------------------------------------------------------------------
>> 
>> Standard: C++03
>> 
>> ---
>> From the documentation: Parse and format C++ constructs compatible with this 
>> standard.
> 
> Since I continue to be puzzled - iirc you said this is because of lack
> of availability of "C99" as a value here. What's entirely unclear to
> me is: How does this matter to a tool checking coding style (which is
> largely about formatting, not any lexical or syntactical aspects)?
> 
>> This value is used also in Linux.
> 
> Considering how different the two styles are, I don't think this is
> overly relevant.

Ok, maybe I understand your point, you are looking for a reason to declare this 
configurable instead
of not specifying it at all?

If it’s that, from what I understand clang-format will use the default value if 
we don’t specify anything
for this one, so it will take ‘Latest’. I think we should put a value for this 
one to fix it and don’t have
surprises if that behaviour changes and seeing that also in Linux that value is 
fixed increased my
confidence.

However, if you feel that we should not specify it, I’ve done a test and not 
specifying it is not changing
the current output. I can’t say that for a different clang-format version 
though or if changes happen in the
future.


> 
> --------------------------------------------------------------------------------------------------------------------------------------------------------------
>> 
>> 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.
> 
> Like above, the significance of having this list and needing to keep it
> up-to-date is unclear to me. I guess the same also applies to a few
> further settings down from here.

From what I understand, we should give to the formatter tool all the hint 
possible to make it do a good
job, for example here we should maintain a list of our attributes so that 
clang-format doesn’t think the function
below is called __init instead of device_tree_node_matches.

static bool __init device_tree_node_matches(const void *fdt, int node, const 
char *match)
{ ... }

> 
> --------------------------------------------------------------------------------------------------------------------------------------------------------------
>> 
>> 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.
> 
> Ah, just wanted to ask. I agree that we'd better have here only items
> which truly require an exception.

Yes my mistake, I’ll fix the list.

> 
> Jan