This patch supersedes PR #151970 by adding the option
``AllowShortRecordOnASingleLine`` that allows the following formatting:
```c++
struct foo {};
struct bar { int i; };
struct baz
{
int i;
int j;
int k;
};
```
---------
Co-authored-by: owenca <owenpiano@gmail.com>
The current clang-format configuration
option AllowShortFunctionsOnASingleLine uses a single enum
(ShortFunctionStyle) to control when short function definitions can be
merged onto a single line. This enum provides predefined combinations of
conditions
(e.g., None, Empty only, Inline only, Inline including Empty, All).
This approach has limitations:
1. **Lack of Granularity:** Users cannot specify arbitrary combinations
of conditions. For example, a user might want to allow merging
for both empty functions and short top-level functions, but not for
short functions defined within classes. This is not possible with the
current enum options except by choosing All, which might merge more than
desired.
2. **Inflexibility:** Adding new conditions for merging (e.g.,
distinguishing between member functions and constructors, handling
lambdas specifically) would require adding many new combined enum
values, leading to a combinatorial explosion and making the
configuration complex.
3. **Implicit Behavior:** Some options imply others
(e.g., Inline implies Empty), which might not always be intuitive or
desired.
The goal is to replace this single-choice enum with a more flexible
mechanism allowing users to specify a set of conditions that must be met
for a short function to be merged onto a single line.
---------
Co-authored-by: owenca <owenpiano@gmail.com>
Java source files can contain apparent import statements inside block
comments (e.g., showing a code example). These can get mixed up with
real import statements when run through clang-format.
This patch tracks block comments (/* ... */) so that we skip lines that
are inside them.
Fixes#176771
---------
Co-authored-by: Natalia Kokoromyti <knatalia@yost-cm-01-imme.stanford.edu>
Co-authored-by: owenca <owenpiano@gmail.com>
Fixes#88896 by following the approach described in
https://github.com/llvm/llvm-project/pull/95798#discussion_r1649496882.
This adds `LangOptions::AllowLiteralDigitSeparator`, following the
pattern used for `RawStringLiterals` in #88265.
It is enabled by default for C++14 and C23, and the Scanner sets it
explicitly to always allow literals with digit separators in directives.
Originally authored by @tsfn (Yifan Fang, <gatsfn@gmail.com>) in
#158420.
Co-authored-by: Yifan Fang <gatsfn@gmail.com>
Add support for `BasedOnStyle: InheritParentConfig=<directory-path>` in
config files to redirect inheritance to the `.clang-format` or
`_clang-format` file in the `<directory_path>` directory.
Closes#107808
## Summary
Extend `BreakBinaryOperations` to accept a structured YAML configuration
with per-operator break rules and minimum chain length gating via
`PerOperator`.
- **Per-operator rules**: specify break style (`Never`, `OnePerLine`,
`RespectPrecedence`) for specific operator groups
- **Minimum chain length**: only trigger breaking when a chain has N or
more operators
- **Fully backward-compatible**: the simple scalar form
(`BreakBinaryOperations: OnePerLine`) behaves identically to the current
enum value
RFC discussion:
https://discourse.llvm.org/t/rfc-per-operator-granularity-for-breakbinaryoperations/89800
### New YAML syntax
```yaml
BreakBinaryOperations:
Default: Never
PerOperator:
- Operators: ['&&', '||']
Style: OnePerLine
MinChainLength: 3
- Operators: ['|']
Style: OnePerLine
```
### Motivation
`BreakBinaryOperations` operates at the level of all binary operators
simultaneously. Enabling `OnePerLine` for `&&`/`||` condition chains
also forces it on `+`, `|`, and other operators, which may not be
desired. The only workaround today is `// clang-format off`.
## Test plan
- [x] All existing `BreakBinaryOperations` unit tests updated and
passing
- [x] New tests for per-operator rules (`&&`/`||` OnePerLine + default
Never)
- [x] New tests for multiple operator groups (`&&`/`||` + `|`)
- [x] New tests for `MinChainLength` gating (chain of 2 vs 3+)
- [x] Config parse tests for structured YAML form
- [x] RST documentation auto-generated via `dump_format_style.py`
- [x] Release notes updated
This patch introduces a new `AfterComma` value for the
`BreakConstructorInitializers` style option. This style keeps the
constructor initializer colon on the same line as the constructor
declaration and breaks after each comma in the initializer list.
Example formatting:
```cpp
Constructor() : initializer1(),
initializer2()
```
This style provides an alternative to the existing BeforeColon,
BeforeComma, and AfterColon options, allowing developers to maintain the
colon on the constructor line while placing each initializer on its own
line after commas.
---------
Co-authored-by: Perceval <perceval@trilogic.fr>
[clang-format] Add ObjCSpaceBeforeMethodDeclColon option to control
space before Objective-C method return type
This patch introduces the ObjCSpaceBeforeMethodDeclColon style option,
allowing users to add or remove a space between the '-'/'+' and the
return type in Objective-C method declarations (e.g., '- (void)method'
vs '-(void)method').
Includes documentation and unit tests.
normal lines and PP directives.
Handling PP directives differently can be desired, like in #161848.
Changing the default is not an option, there are tests for exactly the
current behaviour.
Replace the `AlwaysBreak` and `BlockIndent` suboptions of
`AlignAfterOpenBracket` with new style options `BreakAfterOpenBracket*`
and `BreakBeforeCloseBracket*` for `*` in `BracedList` for braced list
initializers, `if` for if conditional statements, `Loop` for loop
control statements (for/while), `Switch` for switch statements, and
`Function` for function calls/declarations/definitions.
Deprecates `AlwaysBreak` and `BlockIndent`.
Fixes#67738Fixes#79176Fixes#80123Fixes#151844
Fixes http://llvm.org/PR55487 (#55487)
The code did not match the documentation about Cpp11BracedListStyle.
Changed handling of comments after opening braces, which are supposedly
function call like to behave exactly like their parenthesis counter
part.
Fixes#36459.
after
```Objective-C
- (void)test {
if ([object
respondsToSelector:@selector(
selectorNameThatIsReallyLong:param1:param2:)])
return;
}
```
before
```Objective-C
- (void)test {
if ([object respondsToSelector:@selector
(selectorNameThatIsReallyLong:param1:param2:)])
return;
}
```
Before this patch, the `ObjCMethodExpr` type was assigned to many kinds
of tokens. The rule for allowing breaking the line before the colon on
line TokenAnnotator.cpp:6289 was intended for method declarations and
calls. It matched the parenthesis following `@selector` by mistake. To
fix the problem, this patch adds a new type for `@selector`. Most of the
special things in the code related to the old type is intended for other
constructs. So most of the code related to the old type is not changed
in this patch.
This in effect reverts 05fb8408de23c3ccb6125b6886742177755bd757 and
7e1a88b9d1431e263258e3ff0f729c1fdce342d3, the latter of which
erroneously changed the behavior of formatting `ObjC` header files when
both the default and `ObjC` styles were absent. Now the previous
behavior of treating that as an error is restored.
Fixes#158704
Some languages have the flexibility to use upper or lower case
characters interchangeably in integer and float literal definitions.
I'd like to be able to enforce a consistent case style in one of my
projects, so I added this clang-format style option to control it.
With this .clang-format configuration:
```yaml
NumericLiteralCaseStyle:
UpperCasePrefix: Never
UpperCaseHexDigit: Always
UpperCaseSuffix: Never
```
This line of code:
```C
unsigned long long 0XdEaDbEeFUll;
```
gets reformatted into this line of code:
```C
unsigned long long 0xDEAFBEEFull;
```
-----
I'm new to this project, so please let me know if I missed something in
the process. I modeled this PR from
[IntegerLiteralSeparatorFixer](https://reviews.llvm.org/D140543)
This effectively reverts a4d4859dc70c046ad928805ddeaf8fa101793394 which
didn't fix the problem that `int*,` was not counted as "Left" alignment.
Fixes#150327
The [Google C++ Style
Guide](https://google.github.io/styleguide/cppguide.html#Pointer_and_Reference_Expressions)
is being changed to specify that spaces should go after the
asterisk/ampersand, rather than permitting either before or after on a
file-by-file basis.
The new requirement is:
> When referring to a pointer or reference (variable declarations or
> definitions, arguments, return types, template parameters, etc.),
> you must not place a space before the asterisk/ampersand. Use a
> space to separate the type from the declared name (if present).
The [Google ObjC
style](https://google.github.io/styleguide/objcguide.html) is silent on
this matter, but the de-facto style is not being modified at this time.
So, keep DerivePointerAlignment enabled for ObjC language mode.
Sorting by stem gives nicer results when various header file names are
substrings of other header file names. For example, a CLI application
with a main header named analyze.h and an analyze-xxx.h header for each
subcommand currently will always put analyze.h last after all the
analyze-xxx.h headers, but putting analyze.h first instead is arguably
nicer to read.
TLDR; Instead of
```
#include "analyze-blame.h"
#include "analyze.h"
```
You'd get
```
#include "analyze.h"
#include "analyze-blame.h"
```
Let's allow sorting by stem instead of full path by adding
IgnoreExtension to SortIncludes.
This PR addresses instances of compiler warning C4146 that can be
replaced with std::numeric_limits. Specifically, these are cases where a
literal such as '-1ULL' was used to assign a value to a uint64_t
variable. The intent is much cleaner if we use the appropriate
std::numeric_limits value<Type>::max() for these cases.
Addresses #147439
This allows simplification of code that checks if a token is an
Objective-C keyword.
Also, delete the following in
UnwrappedLineParser::parseStructuralElement():
- an else-after-break in the tok::at case
- the copypasted code in the tok::objc_autoreleasepool case
