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 4986f3f2f2 (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 ddaa9be978. 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
bb4f6c4dca 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
New:
```
module mh1
(input var int in1,
input var in2, in3,
output tagged_st out);
endmodule
```
Old:
```
module mh1
(input var int in1, input var in2, in3, output tagged_st out);
endmodule
```
`getNextNonComment` was modified to return a non-const pointer because
we needed to use it that way in `verilogGroupDecl`.
The comment on line 2626 was a typo. We corrected it while modifying
the function.
Reviewed By: MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D143825
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
Token annotator incorrectly annotates operator& as a reference type in
situations like Boost serialization archives:
https://www.boost.org/doc/libs/1_81_0/libs/serialization/doc/tutorial.html
Add annotation rules for standalone and chained operator& instances while
preserving behavior for reference declarations at class scope. Add tests to
validate annotation and formatting behavior.
Differential Revision: https://reviews.llvm.org/D141959
There should not be any cases where the angle brackets of template
parameters are directly followed by a literal. It is more likely that a
comparison is taking place instead.
This patch makes the TokenAnnotator prefer to annotate < and > as
operators when directly followed by a literal. A similar check already
exists for literals directly *before* potential template args.
Fixes https://github.com/llvm/llvm-project/issues/60140
Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D142139
This reverts commit 879bfe6a97.
owenpan@ pointed out on https://reviews.llvm.org/D140956 that this
actually makes the formatting more consistent, so it's not a regression.
This patch properly recognizes the generic selection expression
introduced in C11, by adding an additional token type for the colons
present in such expressions.
Previously, they would be recognized as
"inline ASM colons" purely by the fact that those are the last thing
checked for.
I tried to avoid adding an addition token type, but since colons by
default like having spaces around them, I chose to add a new type so
that no space is added after the type selector.
Currently, no aspect of the formatting of these expressions in able to
be configured, as I'm not sure what could even be configured here.
One notable thing is that association list is always formatted as
either entirely on one line, if it can fit, or with line breaks
after every comma in the expression (also after the controlling expr.)
This visually makes them more similar to switch statements when long,
matching the behaviour of the selection expression, being that of a sort
of switch on types, but also allows for terseness when only selecting
for a few things.
Fixes https://github.com/llvm/llvm-project/issues/18080
Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D139211
Previously, clang-format relied on a special method to parse concept
definitions, `UnwrappedLineParser::parseConcept()`, which deferred to
`UnwrappedLineParser::parseConstraintExpression()`. This is problematic,
because the C++ grammar treats concepts and requires clauses
differently, causing issues such as https://github.com/llvm/llvm-project/issues/55898 and https://github.com/llvm/llvm-project/issues/58130.
This patch removes `parseConcept`, letting the formatter parse concept
definitions as more like what they actually are, fancy bool definitions.
NOTE that because of this, some long concept definitions change in their
formatting, as can be seen in the changed tests. This is because of a
change in split penalties, caused by a change in MightBeFunctionDecl on
the concept definition line, which was previously `true` but with this
patch is now `false`.
One might argue that `false` is a more "correct" value for concept
definitions, but I'd be fine with setting it to `true` again to maintain
compatibility with previous versions.
Fixes https://github.com/llvm/llvm-project/issues/58130
Depends on D140330
Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D140339
