Re: Clang-format configuration discussion - pt 2

[Luca Fancellu <Luca.Fancellu@xxxxxxx>]

> On 24 Nov 2023, at 12:24, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> 
> On 24.11.2023 12:59, Luca Fancellu wrote:
>> @@ -3333,19 +3318,18 @@ static int __init alloc_domain_evtchn(struct 
>> dt_device_node *node)
>> rc = evtchn_alloc_unbound(&alloc_unbound, domU1_port);
>> if ( rc < 0 )
>> {
>> - printk(XENLOG_ERR
>> - "evtchn_alloc_unbound() failure (Error %d) \n", rc);
>> + printk(XENLOG_ERR "evtchn_alloc_unbound() failure (Error %d) \n", rc);
>> return rc;
>> }
>> - bind_interdomain.remote_dom = d1->domain_id;
>> + bind_interdomain.remote_dom = d1->domain_id;
>> bind_interdomain.remote_port = domU1_port;
>> rc = evtchn_bind_interdomain(&bind_interdomain, d2, domU2_port);
>> if ( rc < 0 )
>> {
>> 
>> Assignment of bind_interdomain.remote_dom was aligned with the following 
>> line, but since the value
>> of this configurable is “None”, clang-format is modifying that to use only 
>> one space before the assignment
>> operator.
> 
> Neither here nor ...
> 
>> One example related to macros can be found on line 1663:
>> 
>> diff --git a/xen/arch/arm/arm32/insn.c b/xen/arch/arm/arm32/insn.c
>> index 49953a042a..1635c4b6d1 100644
>> --- a/xen/arch/arm/arm32/insn.c
>> +++ b/xen/arch/arm/arm32/insn.c
>> @@ -19,9 +19,9 @@
>> #include <asm/insn.h>
>> /* Mask of branch instructions' immediate. */
>> -#define BRANCH_INSN_IMM_MASK GENMASK(23, 0)
>> +#define BRANCH_INSN_IMM_MASK GENMASK(23, 0)
>> /* Shift of branch instructions' immediate. */
>> -#define BRANCH_INSN_IMM_SHIFT 0
>> +#define BRANCH_INSN_IMM_SHIFT 0
>> 
>> Clang format sees the comment between BRANCH_INSN_IMM_MASK and 
>> BRANCH_INSN_IMM_SHIFT and
>> even if before the value of the macros were aligned, it applies the rule of 
>> one space between the macro name
>> and the value.
> 
> ... here there is any change in the formatting on the lines in question.
> I was first suspecting a possible issue with my mail UI, but
> https://lists.xen.org/archives/html/xen-devel/2023-11/msg02132.html
> looks to confirm the issue to more likely be on your end (apparently also
> resulting in leading whitespace having been dropped).

Yes indeed, it seems that copy paste removed the original formatting,
but these snippets can be checked in the patch file I linked, I’ve added
a line number.
Sorry for the inconvenience.

Cheers,
Luca