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
A bug with BlockIndent prevents line breaks within if (and else if)
clauses.
While fixing this bug, it appears that AlignAfterOpenBracket is not
designed to work with loop and if statements, but AlwaysBreak works on
if clauses. The documentation and tests are not clear on whether or not
this behavior is intended.
This PR preserves the `AlwaysBreak` behavior on `if` clauses without
supporting `BlockIndent` on `if` clauses to avoid regressions while
fixing the bug.
It may be reasonable to create an explicit option for alignment of if
(and loop) clauses intentionally for both `AlwaysBreak` and
`BlockIndent`
Fixes#54663.
Migrated from Differential Revision: https://reviews.llvm.org/D154755
See more discussion there. Addressed last open comment from the rev
about refactoring the complex conditional logic involved with the
`AlignAfterOpenBracket` line break behavior.
clang-format has logic to align declarations of multiple variables of
the same type, aligning them at the equals sign. This logic is applied
in for loops as well. However, this alignment logic also erroneously
affected the equals signs of designated initializers.
This patch forbids alignment if the token 2 tokens back from the equals
sign is a designated initializer period.
Fixes https://github.com/llvm/llvm-project/issues/73902
Fixesllvm/llvm-project#62904
`AlignArrayOfStructures: Left` combined with `SpacesInParentheses: true`
causes the first cell of every row to have 1 additional space.
We were only setting the first cell of the first row to be against the
left brace, now every row will be against the left brace.
This addresses a problem with formatting attributes. Some context:
- eaff083035c8 changed `isStartOfName` to fix problems inside
`#pragma`s, but this behavior changed formatting of attribute macros in
an undesirable way.
- efeb546865c233dfa7706ee0316c676de9f69897 changed Google format style
to fix some widely used attributes.
Instead of changing the format style, this commit specializes behavior
introduced in eaff083035c8 to `#pragma`s. This seems to work well in
both cases.
Also update the test with two `GUARDED_BY` directives. While the
formatting after efeb546865c233dfa7706ee0316c676de9f69897 seems better,
this case is rare enough to not warrant the extra complexity. We are
reverting it back to the state it had before
efeb546865c233dfa7706ee0316c676de9f69897.
---------
Co-authored-by: Owen Pan <owenpiano@gmail.com>
Done as requested in llvm/llvm-project#77045
I have changed the test a bit, because since the root problem was fixed,
the original test would possibly never crash.
Fixesllvm/llvm-project#76716
Fixes parsing of `[0]{}`. Before this patch it was begin parsed as a
lambda, now it is correctly parsed as a designator initializer.
