[clang-format] Fix bugs in annotating r_paren as C-style cast

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_consta

[clang-format] Fix bugs in annotating r_paren as C-style cast

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

show more ...

[clang-format] Preserve AmpAmpTokenType in nested parentheses

When parsing a requires clause, the UnwrappedLineParser would delegate to
parseParens with an AmpAmpTokenType set to BinaryOperator. How

[clang-format] Preserve AmpAmpTokenType in nested parentheses

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

show more ...

[clang-format] Adjust braced list detection (reland 6dcde65)

This is a retry of https://reviews.llvm.org/D114583, which was backed
out for regressions.

Clang Format is detecting a nested scope foll

[clang-format] Adjust braced list detection (reland 6dcde65)

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

show more ...

[clang-format] Revert 6dcde65 due to missing commit message title

This reverts commit 6dcde658b2380d7ca1451ea5d1099af3e294ea16.

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

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

show more ...

[clang-format] Don't allow template to be preceded by closing brace

This check is similar to the right paren check right below it, but it
doesn't need the overloaded operator check.

This patch prev

[clang-format] Don't allow template to be preceded by closing brace

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

show more ...

[clang-format] Recognize Verilog edge identifiers

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 wit

[clang-format] Recognize Verilog edge identifiers

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

show more ...

[clang-format] Recognize Verilog type dimension in module header

We had the function `verilogGroupDecl` for that. However, the type
name would be incorrectly annotated in `isStartOfName` when it wa

[clang-format] Recognize Verilog type dimension in module header

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

show more ...

[clang-format] Correctly format goto labels followed by blocks

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.

s

[clang-format] Correctly format goto labels followed by blocks

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

show more ...

[clang-format] C# short ternary operator misinterpreted as a CSharpNullable

Refactor the CSharpNullable assignment code to be a little easier to read (Honestly I don't like it when an if expression

[clang-format] C# short ternary operator misinterpreted as a CSharpNullable

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

show more ...

[clang-format][NFC] Output tokens on test assert

Reviewed By: rymiel

Differential Revision: https://reviews.llvm.org/D148482

[clang-format] Handle Verilog assertions and loops

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

[clang-format] Handle Verilog assertions and loops

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

show more ...

Revert "[clang-format] Handle object instansiation in if-statements"

This reverts commit 70de684d44135b4025d92b2b36ad387cf5ab8b5a.

This causes a regression as described in #61785

[clang-format] Don't modify template arguments on the LHS of assignment

After clang-format has determined that an equals sign starts an
expression, it will also go backwards and modify any star/amp/

[clang-format] Don't modify template arguments on the LHS of assignment

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

show more ...

[clang-format] Add option for having one port per line in Verilog

We added the option `VerilogBreakBetweenInstancePorts` to put ports on
separate lines in module instantiations. We made it default

[clang-format] Add option for having one port per line in Verilog

We added the option `VerilogBreakBetweenInstancePorts` to put ports on
separate lines in module instantiations. We made it default to true
because style guides mostly recommend it that way for example:

https://github.com/lowRISC/style-guides/blob/master/VerilogCodingStyle.md#module-instantiation

Reviewed By: HazardyKnusperkeks

Differential Revision: https://reviews.llvm.org/D147327

show more ...

[clang-format] Don't allow variable decls to have trailing return arrows

The heuristic for determining if an arrow is a trailing return arrow
looks for the auto keyword, along with parentheses. This

[clang-format] Don't allow variable decls to have trailing return arrows

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

show more ...

[clang-format] Don't format typename template parameters as expression

bb4f6c4dca98a47054117708015bb2724256ee83 made it so that template
parameter defaults are seen akin to assignments and formatted

[clang-format] Don't format typename template parameters as expression

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

show more ...

[clang-format] Don't misannotate left squares as lambda introducers

A left square can start a lambda only if it's not preceded by an
identifier other than return and co-wait/co-yield/co-return.

Fix

[clang-format] Don't misannotate left squares as lambda introducers

A left square can start a lambda only if it's not preceded by an
identifier other than return and co-wait/co-yield/co-return.

Fixes #54245.
Fixes #61786.

Differential Revision: https://reviews.llvm.org/D147295

show more ...

[clang-format] Don't annotate left brace of struct as FunctionLBrace

Related to a02c3af9f19d. Fixes #61700.

Differential Revision: https://reviews.llvm.org/D146895

[clang-format] Treat NTTP default values as expressions

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

[clang-format] Treat NTTP default values as expressions

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

show more ...

[clang-format] Annotate lambdas with requires clauses.

The C++ grammar allows lambdas to have a *requires-clause* in two
places, either directly after the *template-parameter-list*, such as:

`[] <t

[clang-format] Annotate lambdas with requires clauses.

The C++ grammar allows lambdas to have a *requires-clause* in two
places, either directly after the *template-parameter-list*, such as:

`[] <typename T> requires foo<T> (T t) { ... };`

Or, at the end of the *lambda-declarator* (before the lambda's body):

`[] <typename T> (T t) requires foo<T> { ... };`

Previously, these cases weren't handled at all, resulting in weird
results.

Note that this commit only handles token annotation, so the actual
formatting still ends up suboptimal. This is mostly because I do not yet
know how to approach making the requires clause formatting of lambdas
match the formatting for functions.

Fixes https://github.com/llvm/llvm-project/issues/61269

Reviewed By: HazardyKnusperkeks, owenpan

Differential Revision: https://reviews.llvm.org/D145642

show more ...

[clang-format] Annotate noexcept, explicit specifiers as containing expressions

The noexcept specifier and explicit specifier can optionally include a
boolean expression to make these specifiers app

[clang-format] Annotate noexcept, explicit specifiers as containing expressions

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

show more ...

Reland [clang-format] Add a space between an overloaded operator and '>'

The token annotator doesn't annotate the template opener and closer
as such if they enclose an overloaded operator. This caus

Reland [clang-format] Add a space between an overloaded operator and '>'

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

show more ...

Revert "[clang-format] Add a space between an overloaded operator and '>'"

This reverts commit b05dc1b8766a47482cae432011fd2faa04c83a3e.

Makes clang-format crash on `struct Foo { operator enum foo{

Revert "[clang-format] Add a space between an overloaded operator and '>'"

This reverts commit b05dc1b8766a47482cae432011fd2faa04c83a3e.

Makes clang-format crash on `struct Foo { operator enum foo{} };`

show more ...

[clang-format] Treat &/&& as reference when followed by requires clause

Previously, the token annotator would get confused and annotate a member
function's ref qualifier as a binary operator, if sai

[clang-format] Treat &/&& as reference when followed by requires clause

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

show more ...