[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Clang-format configuration discussion - pt 1


  • To: Luca Fancellu <Luca.Fancellu@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 13 Nov 2023 17:27:54 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=CTfwVAAGNJbo80mRwH3YHpLQMH9zM6BdSYonh0KCeJQ=; b=Fi8U7ehD6GTTWMviM/RgLON9K0lwur4kcO+LWFUH91mYUhvuWOIlT27PbMRzMrhpFxvDbIflDIyVbUwmNSZDCTwXZYzDShlZXVcIaz+KYSHDXmvjKSqDBsGpaUEcenhgxP882uYdRJMYxGJY2Q3Q0hD0LXe7f8SKKAabSc2IX10Vz/hvUTO2GFTWlt5GZjOmHtLe1c48Bk8KRvmt7GqP3sAuZUIN6ovS16I/8ZZ9BiKl7PEkSP8cnSLLJo3WaxeWUxHi5KfKx3xfV2b9MDrmU750C4+VyDRk/hdJQuiu+9ihJT60MXI08JRgxtUuHW0LkSg9yr00lvQRANAKTmUQTQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gQDzEXveT4oaJxEqaiH+DYQu9xqCHKSlud7H60gSuJnxlNnsJOMyGWlVJXFo1Q57kOaSUIR3TAzYw58WEl2q8E1KiQwNmSBQM+fX10EljyXPdFGVXqQUbt/6kt6U4eppCbJvY4imPHgNSfVvEPmejG1TMSSAgO3g79EyFvTipuC36yecdC5LKMJHGSGGAhu7bnimTYpJcSSoEZrzsarYUzLykck4ifmlWgioa8ftjpwlT1tlG0DxHi+eS0ihJwRin9qHtbRKyBMOJUzK6EFgzm9zC+wMyr2TOQK0bkNC5/TLOZBAsuBJ9gh14FH78hDkeLIbRiprf9t0BCQLHv3Kzw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Michal Orzel <Michal.Orzel@xxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Mon, 13 Nov 2023 16:28:10 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 13.11.2023 16:20, Luca Fancellu wrote:
>> 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?

Not really, no. Here I was merely saying that with the styles being
sufficiently different, what Linux uses is probably not very significant
for our own decision.

> 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.

It's fine to set values. All I'm saying is that at least I would prefer
if it was also clear what exact effect the setting of a value has,
especially when that does not really match the language we use in the
project.

>> --------------------------------------------------------------------------------------------------------------------------------------------------------------
>>>
>>> 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)
> { ... }

Well, perhaps they indeed need to do some level of syntax analysis, in
which case knowing which identifiers act as attributes is likely going
to help. Which is where the "needs keeping up-to-date" aspect comes into
play. The example above is simple enough that I wouldn't think a parser
needs to guess what this represents, but presumably there are cases
where ambiguities might arise. (I also wouldn't exclude that the more
involved syntax in C++ increases the desire to have apriori knowledge on
the purpose of certain identifiers. In the end, as per above, the tool
is being told to expect C++ code.)

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.