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
(0e63f1aacc00 was reverted by 7590b7657004 due to a crash.)
Annotate constructor/destructor names as FunctionDeclarationName.
Fixes#63046.
Differential Revision: https://reviews.llvm.org/D157963
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 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
If a non-keyword identifier is found in TypeNames, then a *, &, or && that
follows it is annotated as TT_PointerOrReference.
Differential Revision: https://reviews.llvm.org/D155273
The operator keyword preceded by a template closer should be annotated as
TT_FunctionDeclarationName.
Fixes#63879.
Differential Revision: https://reviews.llvm.org/D155358
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
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
Don't annotate r_paren as TT_CastRParen if it's followed by an amp/star and
either the line is in a macro definition or a numeric_constant follows the
amp/star.
Fixes#59634.
Differential Revision: https://reviews.llvm.org/D153745
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
Before:
```
module x
#( //
parameter x)
( //
input y);
endmodule
```
After:
```
module x
#(//
parameter x)
(//
input y);
endmodule
```
If the first line in a port or parameter list is not a comment, the
following lines will be aligned to the first line as intended:
```
module x
#(parameter x1,
parameter x2)
(input y,
input y2);
endmodule
```
Previously, the indentation would be changed to an extra continuation
indentation relative to the start of the parenthesis or the hash if
the first token inside the parentheses was a comment. It is a feature
introduced in ddaa9be97839. The feature enabled one to insert a `//`
comment right after an opening parentheses to put the function
arguments on a new line with a small indentation regardless of how
long the function name is, like this:
```
someFunction(anotherFunction( // Force break.
parameter));
```
People are unlikely to use this feature in a Verilog port list because
the formatter already puts the port list on its own lines. A comment
at the start of a port list is probably a comment for the port on the
next line.
We also removed the space before the comment so that its indentation
would be same as that for a line comment anywhere else in the port
list.
Reviewed By: HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D149562
We had the function `verilogGroupDecl` for that. However, the type
name would be incorrectly annotated in `isStartOfName` when it was not
a C++ keyword and followed another identifier.
Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D149352
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
Refactor the CSharpNullable assignment code to be a little easier to read (Honestly I don't like it when an if expression get really long and complicated).
Handle the case where '?' is actually a ternary operator.
Fixes: #58067
Reviewed By: owenpan, HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D148473
Assert statements in Verilog can optionally have an else part. We
handle them like for `if` statements, except that an `if` statement in
the else part of an `assert` statement doesn't get merged with the
`else` keyword. Like this:
assert (x)
$info();
else
if (y)
$info();
else if (z)
$info();
else
$info();
`foreach` and `repeat` are now handled like for or while loops.
We used the type `TT_ConditionLParen` to mark the condition part so
they are handled in the same way as the condition part of an `if`
statement. When the code being formatted is not in Verilog, it is
only set for `if` statements, not loops. It's because loop conditions
are currently handled slightly differently, and existing behavior is
not supposed to change. We formatted all files ending in `.cpp` and
`.h` in the repository with and without this change. It showed that
setting the type for `if` statements doesn't change existing behavior.
And we noticed that we forgot to make the program print the list of
tokens when the number is not correct in `TokenAnnotatorTest`. It's
fixed now.
Reviewed By: HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D147895
After clang-format has determined that an equals sign starts an
expression, it will also go backwards and modify any star/amp/ampamp
binary operators on the left side of the assignment to be
pointers/references instead.
There already exists logic to skip over contents of parentheses and
square brackets, but this patch also expands that logic to apply to
angle brackets. This is so that binary operators inside of template
arguments would not be touched, primary arguments to non-type template
parameters.
Fixes https://github.com/llvm/llvm-project/issues/62055
Reviewed By: owenpan, MyDeveloperDay, HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D148024
The heuristic for determining if an arrow is a trailing return arrow
looks for the auto keyword, along with parentheses. This isn't
sufficient, since it also triggers on variable declarations with an auto
type, and with an arrow operator.
This patch makes sure a function declaration is being parsed, instead of
any other declaration.
Fixes https://github.com/llvm/llvm-project/issues/61469
Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D147377
bb4f6c4dca98a47054117708015bb2724256ee83 made it so that template
parameter defaults are seen akin to assignments and formatted as
expressions, however, the patch did this for all template parameters,
even for `typename` template parameters.
This patch formats `typename` and `class` template parameters as types.
Fixes https://github.com/llvm/llvm-project/issues/61841
Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D147318
I've seen a couple of request for extra Json formatting to match prettier capability.
Reviewed By: owenpan
Differential Revision: https://reviews.llvm.org/D147003
An escaped identifier always needs a space following it so the parser
can tell it apart from the next token.
The unit tests are changed to use `FormatTestBase.h` because we need the
2-argument version of `verifyFormat`. We also added the `messUp`
virtual function because Verilog needs a different version of it.
Reviewed By: HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D146401
clang-format already has logic to threat the right-hand side of an
equals sign. This patch applies that logic to template defaults,
which are likely to be non-template type parameters in which case the
default value should be annotated as an expression.
This should mostly only ever apply to bool and &&.
Fixes https://github.com/llvm/llvm-project/issues/61664
Reviewed By: MyDeveloperDay, owenpan
Differential Revision: https://reviews.llvm.org/D146760
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
The token annotator doesn't annotate the template opener and closer
as such if they enclose an overloaded operator. This causes the
space between the operator and the closer to be removed, resulting
in invalid C++ code.
Fixes#58602.
Differential Revision: https://reviews.llvm.org/D143755
Back in D128714, we should have replaced the old rule about colons when
we added the new one. Because we didn't, all colons got mistaken as
case colons as long as the line began with `case` or `default`. Now we
remove the rule that we forgot to remove.
Reviewed By: MyDeveloperDay, rymiel
Differential Revision: https://reviews.llvm.org/D145888
Previously, the token annotator would get confused and annotate a member
function's ref qualifier as a binary operator, if said function also had
a requires clause after it.
This patch accounts for that, treating requires clauses more similarly
to `noexcept`, which also comes after the ref qualifier.
Fixes https://github.com/llvm/llvm-project/issues/61270
Reviewed By: HazardyKnusperkeks, owenpan
Differential Revision: https://reviews.llvm.org/D145656
The small `Coverage` test was added because we added the space rule
about 2 at signs along with the rule about only 1 of it. We have not
fully covered covergroup yet.
Reviewed By: MyDeveloperDay, owenpan
Differential Revision: https://reviews.llvm.org/D145794
Add configuration to specify macros.
Macros will be expanded, and the code will be parsed and annotated
in the expanded state. In a second step, the formatting decisions
in the annotated expanded code will be reconstructed onto the
original unexpanded macro call.
Eventually, this will allow to remove special-case code for
various macro options we accumulated over the years in favor of
one principled mechanism.
Differential Revision: https://reviews.llvm.org/D144170
For example, use 'Next' instead of 'Next != nullptr',
and '!Next' instead of 'Next == nullptr'.
Differential Revision: https://reviews.llvm.org/D144355
