From: Kevin Buettner <kevinb@redhat.com>
To: Tom Tromey <tom@tromey.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH v6] Add .clang-format
Date: Tue, 10 Feb 2026 18:00:13 -0700 [thread overview]
Message-ID: <20260210180013.44cec281@f42-mesa-1> (raw)
In-Reply-To: <20260205224851.1629635-1-tom@tromey.com>
On Thu, 5 Feb 2026 15:48:49 -0700
Tom Tromey <tom@tromey.com> wrote:
> This patch adds a .clang-format file to the gdb repository.
>
> The resulting reformatting is what I'd describe as "ok but not great".
> There are a few variances from our normal style, some discussed in
> comments in the file, and some in the bug.
>
> I've somewhat come around to the idea that some ugliness is
> acceptable, particularly because I regularly see code that's already
> ugly anyway -- either in formatting or along some other dimension.
>
> I don't know of a way to enforce a particular version. I have only
> tried clang-format 18 with this particular file, though Kevin Buettner
> reported trying 19-21 as well. I've documented this in the file.
>
> I used "AllowShortFunctionsOnASingleLine: InlineOnly" as previously
> discussed. I feel that the spirit of the GNU style is that vertical
> space is free, and we should use "None" here. (This goes against
> something we previously decided on the list, though.)
>
> The file is in the root directory for ease of use.
>
> For the time being you should not bulk reformat files. I think we
> should have a flag day for this, but at some later point. See the
> earlier discussion for details.
>
> New in v4:
> * Comment fixes
> * Remove ForEachMacros - no longer correct
> * Remove IncludeCategories - no longer correct
>
> New in v5:
> * More fixes to the comments
>
> New in v6:
> * Removed 'StatementMacros' setting, we're no longer using
> PyObject_HEAD
>
> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30098
> ---
> .clang-format | 167 ++++++++++++++++++++++++++++++++++++++++++++++++++
> .gitignore | 1 -
> 2 files changed, 167 insertions(+), 1 deletion(-)
> create mode 100644 .clang-format
I was around back in the days when we used to use gnu-indent with a
particular set of options. We all agreed that it wasn't perfect - in
fact for many things it was downright ugly. But we also agreed that
it was better than the alternative of having no code formatting tool
available.
I'm in favor of this going in. I'll give you an Approved-by in case
you wish to use it.
Kevin
Approved-by: Kevin Buettner <kevinb@redhat.com>
prev parent reply other threads:[~2026-02-11 1:00 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-05 22:48 Tom Tromey
2026-02-11 1:00 ` Kevin Buettner [this message]
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=20260210180013.44cec281@f42-mesa-1 \
--to=kevinb@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=tom@tromey.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox