Fixes#55731
The reported formatting problems were related to ignoring deep nesting
of "simple" functions (causing #54808) and to allowing the trailing
annotation to become separated from the closing parens, which allowed a
break to occur between the closing parens and the trailing annotation.
The fix for the nesting of "simple" functions is to detect them more
carefully. "Simple" was defined in a comment as being a single
non-expression argument. I tried to stay as close to the original intent
of the implementation while fixing the various bad formatting reports.
In the process of fixing these bugs, some latent bugs were discovered
related to how JavaScript Template Strings are handled. Those are also
fixed here.
---------
Co-authored-by: Owen Pan <owenpiano@gmail.com>
The __attribute((specifier-list)) currently is formatted based on the
SpacesInParensOptions.Other (previously, SpacesInParentheses). This
change allows finer control over addition of spaces between the
consecutive parens, and between the inner parens and the list of
attribute specifiers.
Differential Revision: https://reviews.llvm.org/D155529
This is migrated from Phabricator, see more discussion there.
---------
Co-authored-by: Owen Pan <owenpiano@gmail.com>
The options regarding which blank lines are kept are also aggregated.
The new option is `KeepEmptyLines`.
This patch was initially part of 9267f8f19a2e502e. I neglected to check
the server builds before I added it. It broke clangd. Jie Fu fixed the
problem in 4c91b49bab0728d4. I was unaware of it. I thought the main
branch was still broken. I reverted the first patch in
70cfece24d6cbb57. It broke his fix. He reverted it in
c69ea04fb9738db2. Now the feature is added again including the fix.
This reverts commit 9267f8f19a2e502ef5a216c0d52b352b3699d399.
I changed a formatter option. I forgot to update other components that
depend on the formatter when the option name changed.
PR #90161 uncovered a bug that annotates C++ xor as UnaryOperator if
followed by a binary operator. This patch fixes that and all other C++
alternative operator keywords when followed by a binary operator in C.
Fixes#92688.
Reverts commit d68826dfbd98, which changes the previous default behavior
of always breaking before a stream insertion operator `<<` if both
operands are string literals.
Also reverts the related commits 27f547968cce and bf05be5b87fc.
See the discussion in #88483.
- Use 1-parameter verifyFormat() to verify formatted input in LLVM style.
- Pass string literal instead of constructed StringRef to verifyFormat().
- Don't include trailing newlines if not needed.
This adds an option to break function definition parameters, putting
them on the next line after the function's opening paren.
This was a missing step towards allowing styles which require all
function definition parameters be on their own lines.
Closes#62963
When enabling alignment of consecutive declarations and reference right
alignment, the needed space between `& ` and ` = ` is removed in the
following use case.
Problem (does not compile)
```
int a(const Test &= Test());
double b();
```
Expected:
```
int a(const Test & = Test());
double b();
```
Test command:
```
echo "int a(const Test& = Test()); double b();" | clang-format -style="{AlignConsecutiveDeclarations: true, ReferenceAlignment: Right}"
```
This resolves an issue in clang-format where `new` and `delete` were
incorrectly formatted as keywords in C files. The fix modifies
`TokenAnnotator::spaceRequiredBetween` to handle `new` and `delete` when
used as identifiers for function pointers in structs in C code.
The while loop on line 3814 can cause a segmentation fault getting the
Next field on a nullptr. This is because further down, on line 3823,
there is another for loop, which assigns Tok to Tok->Next in its
initializer. This for loop has a condition to check if the result of
that isn't null. If it is, the loop is skipped and we drop back out to
the outer loop, except, now Tok is null, and we try to dereference it
without checking first.
This patch adds a defensive check that returns if Tok->Next is null
before we make it to the second for loop.
Fixes https://github.com/llvm/llvm-project/issues/82328
---------
Co-authored-by: Owen Pan <owenpiano@gmail.com>
Fix an issue where the lambda body left brace could sometimes fail to be
wrapped when AllowShortLambdasOnASingleLine is enabled.
Now, when BraceWrapping.BeforeLambdaBody is enabled, if the brace is not
wrapped, we prevent breaks in the lambda body.
Resolves#81845
new
```C
while (_Generic(x, //
long: x)(x) > x) {
}
while (_Generic(x, //
long: x)(x)) {
}
```
old
```C
while (_Generic(x, //
long: x)(x) > x) {
}
while (_Generic(x, //
long: x)(x)) {
}
```
In the first case above, the second line previously aligned to the open
parenthesis. The 4 spaces did not get added by the fallback line near
the end of getNewLineColumn because there was already some indentaton.
Now the spaces get added explicitly.
In the second case above, without the fake parentheses, the second line
did not respect the outer parentheses, because the LastSpace field did
not get set without the fake parentheses. Now the indentation of the
outer level is used instead.
The RTBS_None option in Clang-format avoids breaking after a short
return type.
However, there was an issue with the behaviour in that it wouldn't take
the leading indentation of the line into account.
This meant that the behaviour wasn't applying when intended.
In order to address this situation without breaking the existing
formatting, RTBS_None has been deprecated.
In its place are two new options for AlwaysBreakAfterReturnType.
The option RTBS_Automatic will break after the return type based on
PenaltyReturnTypeOnItsOwnLine.
The option RTBS_ExceptShortType will take the leading indentation into
account and prevent breaking after short return types.
This allows the inconsistent behaviour of RTBS_None to be avoided and
users to decide whether they want to allow breaking after short return
types or not.
Resolves#78010
