From: Jan Beulich <jbeulich@suse.com>
To: Luca Fancellu <Luca.Fancellu@arm.com>
Cc: "Andrew Cooper" <andrew.cooper3@citrix.com>,
"Roger Pau Monné" <roger.pau@citrix.com>,
"Julien Grall" <julien@xen.org>,
"Stefano Stabellini" <sstabellini@kernel.org>,
"Bertrand Marquis" <Bertrand.Marquis@arm.com>,
"Michal Orzel" <Michal.Orzel@amd.com>,
"George Dunlap" <george.dunlap@citrix.com>,
"Wei Liu" <wl@xen.org>,
"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: Clang-format configuration discussion - pt 1
Date: Mon, 13 Nov 2023 12:31:15 +0100 [thread overview]
Message-ID: <930d7aa7-7573-97d2-e146-ebe68214c0aa@suse.com> (raw)
In-Reply-To: <174FCBBC-3C2F-47E9-936A-F1399DD9AFFB@arm.com>
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.
--------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> 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.
--------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> 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.
Jan
next prev parent reply other threads:[~2023-11-13 11:31 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-08 9:53 Clang-format configuration discussion - pt 1 Luca Fancellu
2023-11-13 11:31 ` Jan Beulich [this message]
2023-11-13 15:20 ` Luca Fancellu
2023-11-13 15:56 ` Alejandro Vallejo
2023-11-13 16:27 ` Jan Beulich
2023-11-14 14:59 ` Luca Fancellu
2023-11-14 15:23 ` Alejandro Vallejo
2023-11-14 15:59 ` Jan Beulich
2023-11-14 16:03 ` Luca Fancellu
2023-11-13 13:45 ` George Dunlap
2023-11-13 15:28 ` Luca Fancellu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=930d7aa7-7573-97d2-e146-ebe68214c0aa@suse.com \
--to=jbeulich@suse.com \
--cc=Bertrand.Marquis@arm.com \
--cc=Luca.Fancellu@arm.com \
--cc=Michal.Orzel@amd.com \
--cc=andrew.cooper3@citrix.com \
--cc=george.dunlap@citrix.com \
--cc=julien@xen.org \
--cc=roger.pau@citrix.com \
--cc=sstabellini@kernel.org \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.