Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
Fix #109768
|
|
Closes #113170.
|
|
(#108241)
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
|
|
Fixes #105898.
|
|
Fixes #92530.
|
|
Closes #92999.
|
|
Also adds AllowShortCaseExpressionOnASingleLine option and
AlignCaseArrows suboption of AlignConsecutiveShortCaseStatements.
Fixes #55903.
|
|
Fixes #37705.
Fixes #47333.
Fixes #47624.
Fixes #58850.
Fixes #75929.
Fixes #87885.
Fixes #89916.
|
|
|
|
|
|
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}"
```
|
|
Fixes #86109.
|
|
(#86150)
The option to specify the style of alignment of the colons inside TableGen's DAGArg.
|
|
This reverts commit b92d6dd704d789240685a336ad8b25a9f381b4cc. See
github.com/llvm/llvm-project/commit/b92d6dd704d7#commitcomment-139992444
We should use a tool like Visual Studio to clean up the headers.
|
|
|
|
To align TableGen consecutive definitions.
|
|
To align colons inside TableGen !cond operators.
|
|
Fixes #79685.
|
|
Fixes llvm/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.
|
|
Fixed #54815.
Fixed #55269.
Fixed #55493.
Fixed #68431.
|
|
Fixed #71825.
|
|
|
|
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.
|
|
pointers"
This reverts commit a84e0b4bdc9999872adbdaafbade8164b197784b.
Fixes #68079.
|
|
When Shift is 0 there does nothing happen in the remainder of the loop,
express that directly.
|
|
…hange
To improve debugging experience.
|
|
To improve debugging experience.
|
|
(#67955)"
Reland 6a621ed8e4cb 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.
|
|
(#67955)"
This reverts commit 6a621ed8e4cb02bd55fe4a4a0254615576b70a55 as it caused
buildbots to fail.
|
|
After annotating constructors/destructors as FunctionDeclarationName in
commit 08630512088, 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 0468fa07f87f, which is obsolete now.
Fixed #67903.
Fixed #67907.
|
|
Fixes #68102.
|
|
Fixed #67604.
|
|
Fixes #67116.
|
|
|
|
|
|
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 16ccba51072b. The tests caused
assertion failures. Then it was reverted in 547bce36132a.
Reviewed By: MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D154093
|
|
Currently AlignArrayOfStructures=Left is hard coding setting Spaces to
0 for the token following the initial opening brace, but not touching
Spaces for the subsequent lines, which leads to the array being
misaligned. Additionally, it's not adding a space before the trailing
} which is generally done when Cpp11BracedListStyle=false.
I'm not exactly sure why this function needs to override the Spaces as
it seems to generally already be set to either 0 or 1 according to
the other formatting settings, but I'm going with an explicit fix where
I just force the padding to 1 when Cpp11BracedListStyle=false.
AlignArrayOfStructures=Right doesn't have any alignment problems, but
isn't adding the expected padding around the braces either, so I'm
giving that the same treatment.
Fixes #57611.
Differential Revision: https://reviews.llvm.org/D158795
|
|
This fixes https://github.com/llvm/llvm-project/issues/64928.
Differential-Revision: https://reviews.llvm.org/D158945
|
|
Differential Revision: https://reviews.llvm.org/D158571
|
|
This reverts commit 16ccba51072bbc5ff4c66f91f939163dc91e5d96.
This is failing across Linaro's bots e.g.:
https://lab.llvm.org/buildbot/#/builders/188/builds/34393
|
|
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.
Reviewed By: MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D154093
|
|
Fixes https://github.com/llvm/llvm-project/issues/57504.
Differential Revision: https://reviews.llvm.org/D138263
|
|
This adds a new AlignConsecutiveShortCaseStatements option in line with the
existing AlignConsecutive* options , which when
AllowShortCaseLabelsOnASingleLine is enabled will align the tokens after the
case statement's colon. This also adds a AlignCaseColons option to allow
aligning the case label colon itself rather than the token after it.
Fixes #55475.
Differential Revision: https://reviews.llvm.org/D151761
|
|
This reverts commit 4ba00844174db562d2bd8b15dab6aac605eddf57.
|
|
This reverts commit 4f093b31669a4f8e417259583141159586a05b28.
|
|
This reverts commit 4ba00844174db562d2bd8b15dab6aac605eddf57 due to missing
authorship.
|
|
This adds a new AlignConsecutiveShortCaseStatements option in line with the
existing AlignConsecutive* options , which when
AllowShortCaseLabelsOnASingleLine is enabled will align the tokens after the
case statement's colon. This also adds a AlignCaseColons option to allow
aligning the case label colon itself rather than the token after it.
Fixes #55475.
Differential Revision: https://reviews.llvm.org/D151761
|