From: Tom Tromey <tom@tromey.com>
To: gdb-patches@sourceware.org
Cc: Tom Tromey <tom@tromey.com>
Subject: [PATCH v4] Add .clang-format
Date: Mon, 6 Oct 2025 12:38:59 -0600 [thread overview]
Message-ID: <20251006183901.1239002-1-tom@tromey.com> (raw)
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. 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:
* Fix a comment
* Remove ForEachMacros - no longer correct
* Remove IncludeCategories - no longer correct
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30098
---
.clang-format | 174 ++++++++++++++++++++++++++++++++++++++++++++++++++
.gitignore | 1 -
2 files changed, 174 insertions(+), 1 deletion(-)
create mode 100644 .clang-format
diff --git a/.clang-format b/.clang-format
new file mode 100644
index 00000000000..efaa21a4b9a
--- /dev/null
+++ b/.clang-format
@@ -0,0 +1,174 @@
+# -*- yaml -*-
+
+# A clang format style for gdb.
+
+# ⚠️⚠️⚠️ DO NOT BULK REFORMAT FILES ⚠️⚠️⚠️
+
+# This style is still in flux and still considered "alpha". Use "git
+# clang-format" or the like to reformat just the parts your patch
+# touches -- at most. At some point in the future we will bulk
+# reformat and at that point we'll send out new instructions.
+
+# This has only been tried with clang-format 18.
+
+# A few known bugs:
+
+# * Labels are not handled GNU-style.
+# https://github.com/llvm/llvm-project/issues/24492
+# https://github.com/llvm/llvm-project/issues/53717
+
+# * Function call bin-packing is weird.
+# https://github.com/llvm/llvm-project/issues/31255
+# https://github.com/llvm/llvm-project/issues/37051
+# In some spots this means an unavoidable line break just after a
+# "(".
+
+# * gettext calls like "_()" are reformatted to "_ ()"
+# I don't think there's an upstream bug for this yet
+
+# * '#if defined ()' removes the space before the paren:
+# https://github.com/llvm/llvm-project/issues/55292
+
+# * Open brace after a lambda should be on new line.
+# https://github.com/llvm/llvm-project/issues/133135
+
+# * Braced initializers don't put a newline before the "{".
+# Historically gdb was inconsistent about this.
+
+
+# Options here are generally in alphabetical order.
+
+Language: Cpp
+# BasedOnStyle: GNU
+AccessModifierOffset: -2
+AlignAfterOpenBracket: Align
+AlignConsecutiveAssignments: false
+AlignConsecutiveDeclarations: false
+AlignConsecutiveMacros: false
+AlignEscapedNewlines: Left
+AlignOperands: true
+AlignTrailingComments: true
+AllowAllArgumentsOnNextLine: false
+AllowAllParametersOfDeclarationOnNextLine: false
+AllowShortBlocksOnASingleLine: false
+AllowShortCaseLabelsOnASingleLine: false
+AllowShortEnumsOnASingleLine: false
+AllowShortFunctionsOnASingleLine: None
+AllowShortIfStatementsOnASingleLine: Never
+AllowShortLambdasOnASingleLine: All
+AllowShortLoopsOnASingleLine: false
+AlwaysBreakAfterReturnType: TopLevelDefinitions
+AlwaysBreakBeforeMultilineStrings: false
+AlwaysBreakTemplateDeclarations: Yes
+#
+# Run:
+# git grep 'define ATTRIBUTE_' -- include gdb* | \
+# sed -e's/^.*\(ATTRIBUTE_[A-Z0-9_]*\).*$/\1/' | \
+# sort -u | \
+# sed -e "s/^\(.*\)$/ '\1',/"
+AttributeMacros: [
+ 'ATTRIBUTE_ALIGNED_ALIGNOF',
+ 'ATTRIBUTE_COLD',
+ 'ATTRIBUTE_FORMAT_PRINTF_STANDARD',
+ 'ATTRIBUTE_FPTR_PRINTF',
+ 'ATTRIBUTE_GCC_STRUCT',
+ 'ATTRIBUTE_HOT',
+ 'ATTRIBUTE_MALLOC',
+ 'ATTRIBUTE_NOCLONE',
+ 'ATTRIBUTE_NONNULL',
+ 'ATTRIBUTE_NONSTRING',
+ 'ATTRIBUTE_NORETURN',
+ 'ATTRIBUTE_NO_SANITIZE_UNDEFINED',
+ 'ATTRIBUTE_NULL_PRINTF',
+ 'ATTRIBUTE_PACKED',
+ 'ATTRIBUTE_PRINTF',
+ 'ATTRIBUTE_PURE',
+ 'ATTRIBUTE_RESULT_SIZE_1',
+ 'ATTRIBUTE_RESULT_SIZE_1_2',
+ 'ATTRIBUTE_RESULT_SIZE_2',
+ 'ATTRIBUTE_RETURNS_NONNULL',
+ 'ATTRIBUTE_SENTINEL',
+ 'ATTRIBUTE_UNUSED',
+ 'ATTRIBUTE_UNUSED_LABEL',
+ 'ATTRIBUTE_UNUSED_RESULT',
+ 'ATTRIBUTE_USED',
+ 'ATTRIBUTE_VISIBILITY',
+ 'ATTRIBUTE_WARN_UNUSED_RESULT',
+ ]
+BinPackArguments: true
+BinPackParameters: true
+# Because BreakBeforeBraces = GNU, we don't need BraceWrapping.
+BreakBeforeBinaryOperators: All
+BreakBeforeBraces: GNU
+BreakBeforeTernaryOperators: true
+BreakConstructorInitializers: BeforeColon
+BreakInheritanceList: BeforeColon
+BreakStringLiterals: true
+ColumnLimit: 79
+CommentPragmas: 'ARI:'
+CompactNamespaces: false
+ConstructorInitializerIndentWidth: 2
+ContinuationIndentWidth: 2
+Cpp11BracedListStyle: false
+DerivePointerAlignment: false
+DisableFormat: false
+# The docs say not to use this.
+# ExperimentalAutoDetectBinPacking: false
+FixNamespaceComments: true
+IncludeBlocks: Preserve
+# IncludeIsMainRegex: [ not needed ]
+IndentCaseLabels: false
+# See notes at the top of the file -- this is incorrect but that's a
+# clang-format issue.
+IndentGotoLabels: true
+IndentPPDirectives: None
+IndentWidth: 2
+IndentWrappedFunctionNames: false
+KeepEmptyLinesAtTheStartOfBlocks: false
+LineEnding: LF
+# MacroBlockBegin: ''
+# MacroBlockEnd: ''
+MaxEmptyLinesToKeep: 1
+NamespaceIndentation: None
+# NamespaceMacros
+PackConstructorInitializers: Never
+PenaltyBreakAssignment: 50
+PenaltyBreakBeforeFirstCallParameter: 100
+# clang 20 setting:
+# PenaltyBreakBeforeMemberAccess: 50
+# PenaltyBreakComment
+# PenaltyBreakFirstLessLess
+PenaltyBreakOpenParenthesis: 100
+# PenaltyBreakString
+# PenaltyBreakTemplateDeclaration
+# PenaltyExcessCharacter
+# PenaltyReturnTypeOnItsOwnLine
+PointerAlignment: Right
+# RawStringFormats: [ I don't think we need this ]
+# Should be IndentOnly but that requires clang 20.
+ReflowComments: false
+# FIXME - enable
+SortIncludes: Never
+SortUsingDeclarations: true
+SpaceAfterCStyleCast: true
+SpaceAfterLogicalNot: false
+SpaceAfterTemplateKeyword: false
+SpaceBeforeAssignmentOperators: true
+SpaceBeforeCpp11BracedList: true
+SpaceBeforeCtorInitializerColon: true
+SpaceBeforeInheritanceColon: true
+SpaceBeforeParens: Always
+SpaceBeforeRangeBasedForLoopColon: true
+SpaceBeforeSquareBrackets: false
+SpaceInEmptyBlock: false
+SpacesBeforeTrailingComments: 1
+SpacesInAngles: false
+SpacesInContainerLiterals: true
+SpacesInParens: Never
+SpacesInSquareBrackets: false
+Standard: c++17
+# Oh Python...
+StatementMacros: [ 'PyObject_HEAD' ]
+TabWidth: 8
+TypenameMacros: [ 'ENUM_BITFIELD' ]
+UseTab: ForContinuationAndIndentation
diff --git a/.gitignore b/.gitignore
index 7f1c81e00c4..eb44ff7f255 100644
--- a/.gitignore
+++ b/.gitignore
@@ -37,7 +37,6 @@ TAGS.sub
.local.vimrc
.lvimrc
-.clang-format
.clang-tidy
.clangd
.cache
--
2.49.0
next reply other threads:[~2025-10-06 18:39 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-06 18:38 Tom Tromey [this message]
2025-10-06 18:42 ` Tom Tromey
2025-10-06 18:46 ` Andrew Pinski
2025-10-06 19:39 ` Tom Tromey
2025-10-08 22:24 ` Simon Marchi
2025-10-13 6:59 ` Jason Merrill
2025-12-10 19:22 ` Tom Tromey
2025-10-11 22:49 ` Kevin Buettner
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=20251006183901.1239002-1-tom@tromey.com \
--to=tom@tromey.com \
--cc=gdb-patches@sourceware.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox