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.
It did compute the length only on the first line, and thus the following
lines could be (and in the test example were) moved over the column
limit, when the = was aligned.
new
```C++
auto aaaaaaaaaaaaaaaaaaaaa = {}; //
auto b = [] { //
return; //
};
auto aaaaaaaaaaaaaaaaaaaaa = {}; //
auto b = [] { //
return aaaaaaaaaaaaaaaaaaaaa; //
};
```
old
```C++
auto aaaaaaaaaaaaaaaaaaaaa = {}; //
auto b = [] { //
return; //
};
auto aaaaaaaaaaaaaaaaaaaaa = {}; //
auto b = [] { //
return aaaaaaaaaaaaaaaaaaaaa; //
};
```
Aligning a line to another line involves keeping track of the tokens'
positions. Previously the shift was incorrectly added to some tokens
that did not move. Then the comments would end up in the wrong places.
Fixes#52985.
This leaves aligning short case statements with its own logic. But that
is harder to port, because it aligns even with no content of the right
hand side of the :.
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#53497.
Fixes#56078.
after with config `{AlignConsecutiveAssignments: true}`
```C++
auto aaaaaaaaaaaaaaaaaaaaa = {};
auto b = [] {
x = {.one_foooooooooooooooo = 2, //
.two_fooooooooooooo = 3, //
.three_fooooooooooooo = 4};
};
A B = {"Hello "
"World"};
BYTE payload = 2;
float i2 = 0;
auto v = type{i2 = 1, //
i = 3};
```
before
```C++
auto aaaaaaaaaaaaaaaaaaaaa = {};
auto b = [] {
x = {.one_foooooooooooooooo = 2, //
.two_fooooooooooooo = 3, //
.three_fooooooooooooo = 4};
};
A B = {"Hello "
"World"};
BYTE payload = 2;
float i2 = 0;
auto v = type{i2 = 1, //
i = 3};
```
When a line gets aligned, the following lines may need to move with it.
This patch replaces the old algorithm with a simpler one. It uses the
`IsAligned` attribute. It makes most of the scope stack irrelevant.
Now the stack only needs to keep track of 2 levels.
The old algorithm had problems like these.
- Whether lines inside a braced list moved depended on whether there was
a type at the start. It should depend on whether the inside was
aligned to the brace. The first case that came up with a type name at
the start happened to have a comma at the end of the list so the
inside was not aligned to the brace.
- Excluding lines inside closures did not always work.
- A continued string could move twice as much as it should.
The following problems are not fixed yet.
A token that opens a scope is needed. Operator precedence is not
enough.
```C++
auto aaaaaaaaaaaaaaaaaaaaa = {};
auto b = 0 + //
0;
```
The algorithm has trouble when things that should not move and things
that should move are nested. This is related to the `IsAligned`
attribute being a boolean. It also affects how spaces and tabs are
selected.
```C++
auto aaaaaaaaaaaaaaaaaaaaa = {};
auto b = {.a = {
.a = 0,
}};
```
When the style is
`{AlignConsecutiveDeclarations: true, Cpp11BracedListStyle: false}`, the
program would sometimes align the lambda body with the outside. Like
this.
```C++
const volatile auto result{ []() {
const auto something = 1;
return 2;
} };
```
This patch stops it. Now the output looks like this.
```C++
const volatile auto result{ []() {
const auto something = 1;
return 2;
} };
```
Fixes#53699.
The problem was with how the `AlignTokenSequence` function tracked
levels. The stack was pushed once when a token was more nested than the
previous one. It was popped once when a token was less nested than the
previous one. With the option `Cpp11BracedListStyle` disabled, the `[`
token was deeper than the previous token by 2 levels. Both its
indentation level and nesting level were more than that of the previous
one. But the stack was only pushed once. The following tokens popped the
2 levels separately. The function treated the body of the lambda
expression as on the same level as the outside.
The problem is fixed this way. The function `AlignTokens` which calls
the function `AlignTokenSequence` already uses a simpler and more robust
way to track levels. It remembers the outermost level it should align.
It compares the token's level with the outermost level. It does not need
a stack. So it is immune to the problem. This patch makes the function
`AlignTokenSequence` take as a parameter the indices of the tokens
matched by the function `AlignTokens`. This way it does not have to
contain the logic again.
Now the function `AlignTokenSequence` only aligns tokens already matched
by the function `AlignTokens`. It is easy to see that the assertion on
line 453 holds. The workaround on line 354 is not needed any more. The
test on line 20310 added at the same time as the assertion ensures that
the assertion hold.
The stack in the function `AlignTokenSequence` is kept for now. It is
still used to figure out when things inside a level should move along
with the outer level. Since the stack has the problem, the developer
plans to move the logic into token annotator. It already uses a stack.
Enabling AlignConsecutiveDeclarations also aligns function prototypes
or declarations. This is often unexpected as typically function
prototypes, especially in public headers, don't use any padding.
Setting AlignFunctionDeclarations to false will skip this alignment.
It is by default set to true to keep compatibility with prior
versions to not make unexpected changes.
Fixes#74320
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 reverts commit b92d6dd704. See
github.com/llvm/llvm-project/commit/b92d6dd704d7#commitcomment-139992444
We should use a tool like Visual Studio to clean up the headers.
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.
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.
Function pointers are detected as a type of declaration using
FunctionTypeLParen. They are aligned based on rules for
AlignConsecutiveDeclarations. When a function pointer is on the
right-hand side of an assignment, the alignment of the function pointer
can result in excessive whitespace padding due to the ordering of
alignment, as the alignment processes a line from left-to-right and
first aligns the declarations before and after the assignment operator,
and then aligns the assignment operator. Injection of whitespace by
alignment of declarations after the equal sign followed by alignment of
the equal sign results in the excessive whitespace.
Fixes#68079.
We now stop aligning trailing comments on all closing braces, for
classes etc. we even check for the semicolon between the comment and the
brace.
Fixes#67906.
Reland 6a621ed8e4 which failed on Windows but not macOS.
The failures were caused by moving the annotation of the children from the
top to the bottom of TokenAnnotator::annotate(), resulting in invalid lines
including incomplete ones being skipped.
After annotating constructors/destructors as FunctionDeclarationName in
commit 0863051208, we have seen several issues because ctors/dtors had
been treated differently than functions in aligning, wrapping, and
indenting.
This patch annotates ctors/dtors as CtorDtorDeclName instead and would
effectively revert commit 0468fa07f8, which is obsolete now.
Fixed#67903.
Fixed#67907.
Now strings that are too long for one line in C#, Java, JavaScript, and
Verilog get broken into several lines. C# and JavaScript interpolated
strings are not broken.
A new subclass BreakableStringLiteralUsingOperators is used to handle
the logic for adding plus signs and commas. The updateAfterBroken
method was added because now parentheses or braces may be required after
the parentheses or commas are added. In order to decide whether the
added plus sign should be unindented in the BreakableToken object, the
logic for it is taken out into a separate function
shouldUnindentNextOperator.
The logic for finding the continuation indentation when the option
AlignAfterOpenBracket is set to DontAlign is not implemented yet. So in
that case the new line may have the wrong indentation, and the parts may
have the wrong length if the string needs to be broken more than once
because finding where to break the string depends on where the string
starts.
The preambles for the C# and Java unit tests are changed to the newer
style in order to allow the 3-argument verifyFormat macro. Some cases
are changed from verifyFormat to verifyImcompleteFormat because those
use incomplete code and the new verifyFormat function checks that the
code is complete.
The line in the doc was changed to being indented by 4 spaces, that is,
the default continuation indentation. It has always been the case. It
was probably a mistake that the doc showed 2 spaces previously.
This commit was fist committed as 16ccba5107. The tests caused
assertion failures. Then it was reverted in 547bce3613.
Reviewed By: MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D154093
