Function and variable names are not detected when there is a
__attribute__((x)) preceding the name.
Fixes#64137.
Differential Revision: https://reviews.llvm.org/D156370
Pull request #65409 changed the brace kind heuristic to not treat a
preprocessor if directive as a in statement, however, this caused some
regressions.
If the contents of a brace don't immediately determine the brace kind,
the heuristic will look at the characters immediately before and after
the closing brace to determine the brace type.
Unfortunately, if the closing brace was preceded by a preprocessor
directive, for example `#endif`, the preceding token was `endif`, seen
as just an identifier, so the braces were understood as a braced list.
This patch fixes this behaviour by skipping all preprocessor directives
when calculating brace types. Comments were already being skipped, so
now preprocessor lines are skipped alongside comments.
Fixes https://github.com/llvm/llvm-project/issues/68404
Previously, upon encountering an equals sign while parsing a lambda in
the UnwrappedLineParser, it would fall through and fail. This caused any
lambda template with a default argument for a template parameter to be
annotated as an ArraySubscriptLSquare.
This patch allows equals signs in the UnwrappedLineParser if we're
currently in a template parameter list. This resolved a FIXME that was
in the lambda parsing function.
This patch seems deceptively easy, it's likely it doesn't solve the
FIXME entirely, or causes other issues (the FIXME itself mentions
something about Objective-C, which I cannot comment about). However this
patch is sufficient to fix the below issue.
Fixes https://github.com/llvm/llvm-project/issues/68913
---------
Co-authored-by: Owen Pan <owenpiano@gmail.com>
There are two parts to this fix:
- Annotate the paren after an AttributeMacro as an AttributeLParen.
- Treat an AttributeMacro-without-paren the same as one with a paren.
I added a new test-case to differentiate a macro that is or is-not an
AttributeMacro; also handled whether ColumnLimit is set to infinite (0) or a
finite value, as part of this patch is in ContinuationIndenter.
Closes#68722.
Differential Revision: https://reviews.llvm.org/D145262
There are two parts to this fix:
- Annotate the paren after an AttributeMacro as an AttributeLParen.
- Treat an AttributeMacro-without-paren the same as one with a paren.
I added a new test-case to differentiate a macro that is or is-not an
AttributeMacro; also handled whether ColumnLimit is set to infinite (0) or a
finite value, as part of this patch is in ContinuationIndenter.
Closes#68722.
Differential Revision: https://reviews.llvm.org/D145262
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.
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.
clang-format uses a heuristic to determine if a requires() is either a
requires clause or requires expression, based on what is in the
parentheses. Part of this heuristic assumed that a requires clause can
never contain a comma, however this is not the case if said comma is in
the template argument of a type.
This patch allows commas to appear in a requires clause if an angle
bracket `<` has been opened.
Fixes https://github.com/llvm/llvm-project/issues/65904
Dictionary literal keys and strings in TypeScript type declarations can
not be broken.
The problem was pointed out by @alexfh and @e-kud here:
https://reviews.llvm.org/D154093#4644512
When encountering braces, such as those of a designated initializer,
clang-format scans ahead to see what is contained within the braces. If
it found a statement, like an if-statement of for-loop, it would deem
the braces as not an initializer, but as a block instead.
However, this heuristic incorrectly included a preprocessor `#if` line
as an if-statement. This manifested in strange results and discrepancies
between `#ifdef` and `#if defined`.
With this patch, `if` is now ignored if it is preceeded by `#`.
Fixes most of https://github.com/llvm/llvm-project/issues/56685
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
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
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
When parsing a requires clause, the UnwrappedLineParser would delegate to
parseParens with an AmpAmpTokenType set to BinaryOperator. However,
parseParens would not carry this over into any nested parens, meaning it
could assign a different token type to an && in a requires clause.
This patch makes sure parseParens inherits its parameter when performing
a recursive call.
Fixes https://github.com/llvm/llvm-project/issues/63251
Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D153641
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
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
Previously the event expression would be misidentified as a port list.
A line break would be added after the comma. The events can be
separated with either a comma or the `or` keyword, and a line break
would not be inserted if the `or` keyword was used. We changed the
behavior of the comma to match the `or` keyword.
Before:
```
always @(posedge x,
posedge y)
x <= x;
always @(posedge x or posedge y)
x <= x;
```
After:
```
always @(posedge x, posedge y)
x <= x;
always @(posedge x or posedge y)
x <= x;
```
Reviewed By: HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D149561
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
