Removes some 500 newlines (\n and \r\n) at the end of test cases in
FormatTest.cpp.
Also changes a few verifyFormat() to verifyNoChange() in tests
InsertNewlineAtEOF and WhitespaceSensitiveMacros as messUp() removes
trailing newlines as well.
Differential Revision: https://reviews.llvm.org/D158805
Fixes a long-standing bug that erroneously placed function arguments on a
new line despite all arguments being able to fit on the same line.
The original diff that introduced the bug implemented behaviour that pushed
the first argument to a function onto a new line under certain circumstances
relating passing lambdas as arguments.
This behaviour was implemented in TokenAnnotator::mustBreakBefore() which
meant the code lacked the necessary context to figure out whether subsequent
arguments might be able to all fit on one line. As such, I've moved the
implementation to ContinuationIndenter and, instead of forcing a line break
at the first argument in all cases, we now allow the OptimizingLineFormatter
to consider placing the first argument on the same line as the function call
but don't allow further line breaks in this case.
The end result is that either the first argument must go on a new line (as
before) or all arguments must be put on the current line.
Closes#44486.
Differential Revision: https://reviews.llvm.org/D156259
This is a refactoring of:
- SpacesInConditionalStatement
- SpacesInCStyleCastParentheses
- SpaceInEmptyParentheses
- SpacesInParentheses
These are now options under the new Style Option: SpacesInParens. The
existing options are maintained for backward compatibility.
Within SpacesInParens, there are currently options for:
- Never
- Custom
The currently available options for Custom are:
- InConditionalStatements
- InCStyleCasts
- InEmptyParentheses
- Other
Setting InConditionalStatements and Other to true enables the same space
additions as SpacesInParentheses.
This refactoring does not add or remove any existing features, but it makes
it possible to more easily extend and maintain the addition of spaces within
parentheses.
Related to #55428.
Differential Revision: https://reviews.llvm.org/D155239
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 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
The ObjC-block detection code only supports a single token as the return type. Add support to detect pointers, too (ObjC has lots of object-pointers).
For example, using `BasedOnStyle: WebKit`, the following is stable output:
```
int* p = ^int*(void)
{ //
return nullptr;
}
();
```
After the patch, this is stable:
```
int* p = ^int*(void) { //
return nullptr;
}();
```
Differential Review: https://reviews.llvm.org/D146434
C89 and C99 list initializers are treated differently than Cpp11 braced
initializers. This patch identifies the C array/struct initializer lists by
finding the preceding equal sign before a left brace, and applies formatting
rules for BracketAlignmentStyle.BlockIndent to those list initializers.
Fixes#57878.
Differential Revision: https://reviews.llvm.org/D153205
Fixes a bug that prevents alignment from proceeding through a function
pointer in a list of declarations.
Fixes#63451.
Differential Revision: https://reviews.llvm.org/D153585
Fixes a bug with the handling of right aligned references with left/middle
alignment pointers.
Fixes#63452.
Differential Revision: https://reviews.llvm.org/D153579
Reverts 4986f3f2f220 (but keeps its unit tests) and fixes#49973
differently.
Also fixes bugs that incorrectly annotate the operator keyword as
TT_FunctionDeclarationName in function calls and as TT_Unknown in function
declarations and definitions.
Differential Revision: https://reviews.llvm.org/D154184
The annotator correctly annotates an overloaded operator call when
called as a member function, like `x.operator+(y)`, however, when called
as a free function, like `operator+(x, y)`, the annotator assumed it was
an overloaded operator function *declaration*, instead of a call.
This patch allows for a free function call to correctly be annotated as
a call, but only if the current like cannot be a declaration, usually
within the bodies of a function.
Fixes https://github.com/llvm/llvm-project/issues/49973
Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay, Nuullll
Differential Revision: https://reviews.llvm.org/D153798
7a38b3bfeb56 landed after 20b4df1ed611, which refactored how tests are
structured in FormatTest. This quick fix-up unifies the tests added in
7a38b3bfeb56 to comply with this new format.
Previously, using ColumnLimit: 0 with extended inline asm with the
BreakBeforeInlineASMColon: OnlyMultiline option (the default style),
the formatter would act as if in Always mode, meaning a line break was
added before every colon in an extended inline assembly block.
This patch respects the already existing line breaks, and doesn't add
any new ones, if in ColumnLimit 0 mode.
Behaviour with Always stays as expected, with a break before every colon
regardless of any existing line breaks.
Behaviour with Never was broken before, and remains broken with this patch,
it is just never respected in ColumnLimit 0 mode.
Fixes https://github.com/llvm/llvm-project/issues/62754
Reviewed By: HazardyKnusperkeks, owenpan
Differential Revision: https://reviews.llvm.org/D150848
If the first token of an annotated line already has a computed Newlines,
reuse it to avoid potential overlapping whitespace replacements before
preprocessor branching directives.
Fixes#62892.
Differential Revision: https://reviews.llvm.org/D151954
This patch adds a verifyNoChange macro to verify code that won't
change after being formatted. (The code will not be messed up before
being formatted.) It then replaces EXPECT_EQ with verifyFormat
wherever applicable so that the code will be messed up before being
formatted. When the replacement fails the unit test, verifyFormat is
replaced with verifyNoChange.
Differential Revision: https://reviews.llvm.org/D153109
After https://reviews.llvm.org/D151954 we've noticed some issues w/
clang-format behavior, as outlined in
https://github.com/llvm/llvm-project/issues/63170.
Valid C/C++ files, that were previously accepted, are now rejected by
clang-format, emitting the message:
"The new replacement overlaps with an existing replacement."
This reverts commit 4b9764959dc4b8783e18747c1742ab164e4bc4ee and
d2627cf88d2553a4c2e850430bdb908a4b7d2e52, which depends on it.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D152473
This reverts commit 4b9764959dc4b8783e18747c1742ab164e4bc4ee.
Reverting since this causes clang-formtat to incorrectly fall into an
error path yet return a zero exit code despite not formatting the file
at all.
See https://github.com/llvm/llvm-project/issues/63170
Adds an option KeepEmptyLinesAtEOF to keep empty lines (up to
MaxEmptyLinesToKeep) before EOF. This remedies the probably unintentional
change in behavior introduced in 3d3ea84a4f8f, which started to always
remove empty lines before EOF.
Fixes#56054.
Fixes#63150.
Differential Revision: https://reviews.llvm.org/D152305
If the first token of an annotated line is finalized, reuse its
NewlinesBefore value to avoid potential overlapping whitespace
replacements before preprocessor branching directives.
Fixes#62892.
Differential Revision: https://reviews.llvm.org/D151954
This is a retry of https://reviews.llvm.org/D114583, which was backed
out for regressions.
Clang Format is detecting a nested scope followed by another open brace
as a braced initializer list due to incorrectly thinking it's matching a
braced initializer at the end of a constructor initializer list which is
followed by the body open brace.
Unfortunately, UnwrappedLineParser isn't doing a very detailed parse, so
it's not super straightforward to distinguish these cases given the
current structure of calculateBraceTypes. My current hypothesis is that
these can be disambiguated by looking at the token preceding the
l_brace, as initializer list parameters will be preceded by an
identifier, but a scope block generally will not (barring the MACRO
wildcard).
To this end, I am adding tracking of the previous token to the LBraceStack
to help scope this particular case.
TokenAnnotatorTests cherry picked from https://reviews.llvm.org/D150452.
Fixes#33891.
Fixes#52911.
Differential Revision: https://reviews.llvm.org/D150403
out for regressions.
Clang Format is detecting a nested scope followed by another open brace
as a braced initializer list due to incorrectly thinking it's matching a
braced initializer at the end of a constructor initializer list which is
followed by the body open brace.
Unfortunately, UnwrappedLineParser isn't doing a very detailed parse, so
it's not super straightforward to distinguish these cases given the
current structure of calculateBraceTypes. My current hypothesis is that
these can be disambiguated by looking at the token preceding the
l_brace, as initializer list parameters will be preceded by an
identifier, but a scope block generally will not (barring the MACRO
wildcard).
To this end, I am adding tracking of the previous token to the LBraceStack
to help scope this particular case.
TokenAnnotatorTests cherry picked from https://reviews.llvm.org/D150452.
Fixes#33891.
Fixes#52911.
Differential Revision: https://reviews.llvm.org/D150403
When in ColumnLimit 0, the formatter looks for MustBreakBefore in the
line in order to check if a line is allowed to be merged onto one line.
However, since MustBreakBefore is really a property of the gap between
the token and the one previously, I belive the check is erroneous in
checking all the tokens in a line, since whether the previous line ended
with a forced line break should have no effect on whether the current
line is allowed to merge with the next one.
This patch changes the check to skip the first token in
`LineJoiner.containsMustBreak`.
This patch also changes a test, which is not ideal, but I believe the
test also suffered from this bug. The test case in question sets
AllowShortFunctionsOnASingleLine to "Empty", but the empty function in
said test case isn't merged to a single line, because of the very same
bug this patch fixes.
Fixes https://github.com/llvm/llvm-project/issues/62721
Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D150614
This check is similar to the right paren check right below it, but it
doesn't need the overloaded operator check.
This patch prevents brace-initialized objects that are being compared
from being mis-annotated as template parameters.
Fixes https://github.com/llvm/llvm-project/issues/57004
Reviewed By: owenpan, MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D150629
Since 3.8 or earlier, clang-format has been lumping all #else, #elif,
etc blocks together when doing whitespace replacements and causing
consecutive alignments across #else blocks.
Commit c077975 partially addressed the problem but also triggered
"regressions".
This patch fixes the root cause of the problem and "reverts" c077975
(except for the unit tests).
Fixes#36070.
Fixes#55265.
Fixes#60721.
Fixes#61498.
Differential Revision: https://reviews.llvm.org/D150057
There doesn't seem to be an issue on GitHub. But previously, a space
would be inserted before the goto colon in the code below.
switch (x) {
case 0:
goto_0: {
action();
break;
}
}
Previously, the colon following a goto label would be annotated as
`TT_InheritanceColon`. A goto label followed by an opening brace
wasn't recognized. It is easy to add another line to have
`spaceRequiredBefore` function recognize the case, but I believed it
is more proper to avoid doing the same thing in `UnwrappedLineParser`
and `TokenAnnotator`. So now the label colons would be labeled in
`UnwrappedLineParser`, and `spaceRequiredBefore` would rely on that.
Previously we had the type `TT_GotoLabelColon` intended for both goto
labels and case labels. But since handling of goto labels and case
labels differ somewhat, I split it into separate types for goto and
case labels.
This patch doesn't change the behavior for case labels. I added the
lines annotating case labels because they would previously be
mistakenly annotated as `TT_InheritanceColon` just like goto labels.
And since I added the annotations, the checks for the `case` and
`default` keywords in `spaceRequiredBefore` are not necessary anymore.
Reviewed By: MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D148484
The option allows users to specify how many columns to use to indent
the contents of initializer lists.
Closes#51070.
Differential Revision: https://reviews.llvm.org/D146101
When using BraceWrapping.AfterClass or BraceWrapping.AfterStruct, the
token annotator relies on the first token of the line to determine if
we're dealing with a struct or class, however, this check is faulty if
it's actually a function with an elaborated struct/class return type, as
is common in C.
This patch skips the check if the brace is already annotated as
FunctionLBrace, in which case we already know it's a function and should
be treated as such.
Fixes https://github.com/llvm/llvm-project/issues/58527
Reviewed By: HazardyKnusperkeks, owenpan
Differential Revision: https://reviews.llvm.org/D146281
The trailing return type arrow checker verifies that a declaration is
being parsed, however, this isn't true when inside of macros.
It turns out the existence of the auto keyword is enough to make
sure that we're dealing with a trailing return type, and whether we're
in a declaration doesn't matter.
Fixes https://github.com/llvm/llvm-project/issues/47664
Reviewed By: HazardyKnusperkeks, owenpan
Differential Revision: https://reviews.llvm.org/D141811
The noexcept specifier and explicit specifier can optionally include a
boolean expression to make these specifiers apply conditionally,
however, clang-format didn't set the context for the parenthesized
content of these specifiers, meaning they inherited the parent context,
which usually isn't an expressions, leading to misannotated binary
operators.
This patch applies expression context to the content of these
specifiers, making them similar to the static_assert keyword.
Fixes https://github.com/llvm/llvm-project/issues/44543
Reviewed By: owenpan, MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D146284
