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

The l_brace of class/struct/union was incorrectly annotated as
TT_FunctionLBrace in the presence of attributes. This in turn
would

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

The l_brace of class/struct/union was incorrectly annotated as
TT_FunctionLBrace in the presence of attributes. This in turn
would cause the RemoveSemicolon option to remove the semicolon
at the end of the declaration, resulting in invalid code being
generated.

Fixes #61188.

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

show more ...

[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

[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 ...

[clang-format] Recognize Verilog non-blocking assignment

Reviewed By: HazardyKnusperkeks, owenpan

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

[clang-format] Fix inconsistent annotation of operator&

Token annotator incorrectly annotates operator& as a reference type in
situations like Boost serialization archives:
https://www.boost.org/doc

[clang-format] Fix inconsistent annotation of operator&

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

show more ...

[clang-format] Properly handle the C11 _Generic keyword.

This patch properly recognizes the generic selection expression
introduced in C11, by adding an additional token type for the colons
present

[clang-format] Properly handle the C11 _Generic keyword.

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

show more ...

[clang-format] fix template closer followed by >

fix https://github.com/llvm/llvm-project/issues/59785

Reviewed By: HazardyKnusperkeks, MyDeveloperDay, owenpan

Differential Revision: https://revie

[clang-format] fix template closer followed by >

fix https://github.com/llvm/llvm-project/issues/59785

Reviewed By: HazardyKnusperkeks, MyDeveloperDay, owenpan

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

show more ...

[clang-format] Disallow decltype in the middle of constraints

If a function with a `requires` clause as a constraint has a decltype
return type, such as `decltype(auto)`, the decltype was seen to be

[clang-format] Disallow decltype in the middle of constraints

If a function with a `requires` clause as a constraint has a decltype
return type, such as `decltype(auto)`, the decltype was seen to be part
of the constraint clause, rather than as part of the function
declaration, causing it to be placed on the wrong line.

This patch disallows decltype to be a part of these clauses

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

Depends on D140339

Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay

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

show more ...

[clang-format] Set requires expression params as not an expression

Previously, the parens of a requires expression's "parameters" were not
explicitly set, meaning they ended up as whatever the outer

[clang-format] Set requires expression params as not an expression

Previously, the parens of a requires expression's "parameters" were not
explicitly set, meaning they ended up as whatever the outer scope was.
This is a problem in some cases though, since the process of determining
star/amp checks if the token is inside of an expression context

This patch always makes sure the context between those parens are always
set to not be an expression

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

Reviewed By: HazardyKnusperkeks, owenpan

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

show more ...

[clang-format] Remove special case for kw_operator when aligning decls

This change breaks no existing tests but does fix the linked issue.
Declarations of operator overloads are annotated with
`TT_F

[clang-format] Remove special case for kw_operator when aligning decls

This change breaks no existing tests but does fix the linked issue.
Declarations of operator overloads are annotated with
`TT_FunctionDeclarationName` on the `operator` keyword, which is already
being checked for when aligning, so the extra `kw_operator` doesn't seem
to be necessary. (just for reference, it was added in
rG92b397fb9d55ccdf4632c2b1b15b4a0ee417cf74 / 92b397fb9d55ccdf4632c2b1b15b4a0ee417cf74)

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

Reviewed By: HazardyKnusperkeks, owenpan

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

show more ...

[clang-format] Treats &/&& as reference when followed by ',' or ')'

Ran into an issue where function declarations inside function
scopes or uses of sizeof inside a function would treat the && in
'si

[clang-format] Treats &/&& as reference when followed by ',' or ')'

Ran into an issue where function declarations inside function
scopes or uses of sizeof inside a function would treat the && in
'sizeof(Type &&)' as a binary operator.

Attempt to fix this by assuming reference when followed by ',' or
')'. Also adds tests for these.

Also hit an edge case in another test that treated "and" the same
as "&&" since it parses as C++. Changed the "and" to "also" so it
is no longer a keyword.

Fixes #58923.

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

show more ...

[clang-format] Correctly annotate function names before attributes

Fixes #58827.

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

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

Before this patch code like this:

```
if (Class* obj{getObject()}) { }
```

would be mis-formated since the * would be annotated as a
bin

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

Before this patch code like this:

```
if (Class* obj{getObject()}) { }
```

would be mis-formated since the * would be annotated as a
binaryoperator.

This patch changes the * to become a PointerOrReference instead
and fixes the formatting issues.

Reviewed By: HazardyKnusperkeks

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

show more ...

[clang-format] Don't misannotate in CTor init list

They were annotated with TrailingAnnotation, which they are not. And
that resulted in some quirky formatting in some cases.

Differential Revision:

[clang-format] Don't misannotate in CTor init list

They were annotated with TrailingAnnotation, which they are not. And
that resulted in some quirky formatting in some cases.

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

show more ...

[clang-format] Correctly annotate UDLs as OverloadedOperator

While the opening parenthesis of an user-defined literal operator was
correctly annotated as OverloadedOperatorLParen, the "" and its suf

[clang-format] Correctly annotate UDLs as OverloadedOperator

While the opening parenthesis of an user-defined literal operator was
correctly annotated as OverloadedOperatorLParen, the "" and its suffix
wasn't annotated as OverloadedOperator.

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

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

show more ...

[clang-format] Mark pragma region lines as StringLiterals

In our code-base we auto-generate pragma regions the regions
look like method signatures like:

`#pragma region MYREGION(Foo: bar)`

The pro

[clang-format] Mark pragma region lines as StringLiterals

In our code-base we auto-generate pragma regions the regions
look like method signatures like:

`#pragma region MYREGION(Foo: bar)`

The problem here was that the rest of the line after region
was not marked as stringliteral as in the case of pragma mark
so clang-format tried to change the formatting based on the
method signature.

Added test and mark it similar as pragma mark.

Reviewed By: owenpan

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

show more ...

[clang-format] Correctly annotate star/amp in function pointer params

Inside the arguments part of a function pointer declaration,
`determineStarAmpUsage` results in a binary operator rather than
po

[clang-format] Correctly annotate star/amp in function pointer params

Inside the arguments part of a function pointer declaration,
`determineStarAmpUsage` results in a binary operator rather than
pointers, because said parens are assumed to be an expression.

This patch correctly marks the argument parens of a function
pointer type as not an expression. Note that this fix already
existed for Objective-C blocks as part of f1f267b447f60528440d2c066b29ab014ae7f90f.
As Objective-C blocks and C/C++ function pointers share a lot
of the same logic, that fix also makes sense here.

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

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

show more ...

[clang-format] Look ahead before consuming `bool` in requires clause.

The comment handling the bool case says:
"bool is only allowed if it is directly followed by a paren for a cast"

This change mo

[clang-format] Look ahead before consuming `bool` in requires clause.

The comment handling the bool case says:
"bool is only allowed if it is directly followed by a paren for a cast"

This change more closely follows this directive by looking ahead for
the paren before consuming the bool keyword itself. Without a following
paren, the bool would be part of something else, such as a return type
for a function declaration

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

Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay

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

show more ...

[clang-format] Correctly annotate static and consteval lambdas

`P1169` "static operator()" (https://wg21.link/P1169) is accepted to
C++23 and while clang itself doesn't exactly support it yet,
clang

[clang-format] Correctly annotate static and consteval lambdas

`P1169` "static operator()" (https://wg21.link/P1169) is accepted to
C++23 and while clang itself doesn't exactly support it yet,
clang-format could quite easily.

This simply allows the keyword `static` to be a part of lambdas as
specified by the addition to [expr.prim.lambda.general]

While adding this, I noticed `consteval` lambdas also aren't handled,
so that keyword is now allowed to be a part of lambdas as well

Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay

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

show more ...

[clang-format] Disallow requires clauses to become function declarations

There already exists logic to disallow requires *expressions* to be
treated as function declarations, but this expands it to

[clang-format] Disallow requires clauses to become function declarations

There already exists logic to disallow requires *expressions* to be
treated as function declarations, but this expands it to include
requires *clauses*, when they happen to also be parenthesized.

Previously, in the following case:

```
template <typename T>
requires(Foo<T>)
T foo();
```

The line with the requires clause was actually being considered as the
line with the function declaration due to the parentheses, and the
*real* function declaration on the next line became a trailing
annotation

(Together with https://reviews.llvm.org/D134049) Fixes https://github.com/llvm/llvm-project/issues/56213

Reviewed By: HazardyKnusperkeks, owenpan

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

show more ...

[clang-format] Disallow trailing return arrows to be operators

In the following construction:
`template <typename T> requires Foo<T> || Bar<T> auto func() -> int;`

The `->` of the trailing return t

[clang-format] Disallow trailing return arrows to be operators

In the following construction:
`template <typename T> requires Foo<T> || Bar<T> auto func() -> int;`

The `->` of the trailing return type was actually considered as an
operator as part of the binary operation in the requires clause, with
the precedence level of `PrecedenceArrowAndPeriod`, leading to fake
parens being inserted in strange locations, that would never be closed.

Fixes one part of https://github.com/llvm/llvm-project/issues/56213
(the rest will probably be in a separate patch)

Reviewed By: HazardyKnusperkeks, owenpan

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

show more ...

[clang-format] Fix template arguments in macros

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

old
```
#define FOO(typeName, realClass) \
{

[clang-format] Fix template arguments in macros

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

old
```
#define FOO(typeName, realClass) \
{ \
#typeName, foo < FooType>(new foo <realClass>(#typeName)) \
}
```
new
```
#define FOO(typeName, realClass) \
{ #typeName, foo<FooType>(new foo<realClass>(#typeName)) }
```

Previously, when an UnwrappedLine began with a hash in a macro
definition, the program incorrectly assumed the line was a preprocessor
directive. It should be stringification.

The rule in spaceRequiredBefore was added in 8b5297117b. Its purpose is
to add a space in an include directive. It also added a space to a
template opener when the line began with a stringification hash. So we
changed it.

Reviewed By: HazardyKnusperkeks, owenpan

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

show more ...

[clang-format] Change heuristic for locating lambda template arguments

Previously, the heuristic was simply to look for template argument-
specific keywords, such as typename, class, template and au

[clang-format] Change heuristic for locating lambda template arguments

Previously, the heuristic was simply to look for template argument-
specific keywords, such as typename, class, template and auto
that are preceded by a left angle bracket <.

This changes the heuristic to instead look for a left angle bracket <
preceded by a right square bracket ], since according to the C++
grammar, the template arguments must *directly* follow the introducer.
(This sort of check might just end up being *too* aggressive)

This patch also adds a bunch more token annotator tests for lambdas,
specifically for some of the stranger forms of lambdas now allowed as
of C++20 or soon-to-be-allowed as part of C++23.

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

This does NOT resolve the FIXME regarding explicit template lists, but
perhaps it gets closer

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

show more ...

[clang-format] Concepts: allow identifiers after negation

Previously, the formatter would refuse to treat identifiers within a
compound concept definition as actually part of the definition, if
they

[clang-format] Concepts: allow identifiers after negation

Previously, the formatter would refuse to treat identifiers within a
compound concept definition as actually part of the definition, if
they were after the negation operator !. It is now made consistent
with the likes of && and ||.

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

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

show more ...

[clang-format] Allow `throw` to be a keyword in front of casts

This makes throw more similar to return. However, unlike return,
it has to more strict as to not remove spaces after usages of throw as

[clang-format] Allow `throw` to be a keyword in front of casts

This makes throw more similar to return. However, unlike return,
it has to more strict as to not remove spaces after usages of throw as
a (deprecated) exception specifier.

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

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

show more ...

[clang-format] Don't put `noexcept` on empty line following constructor

With the AlwaysBreakTemplateDeclarations option, having a constructor
template for a type consisting of all-uppercase letters

[clang-format] Don't put `noexcept` on empty line following constructor

With the AlwaysBreakTemplateDeclarations option, having a constructor
template for a type consisting of all-uppercase letters with a
noexcept specifier would put said noexcept specifier on its own blank
line.

This is because the all-uppercase type is understood as a macro-like
attribute (such as DEPRECATED()), and noexcept is seen as the
declaration. However, noexcept is a keyword and cannot be an
identifier on its own.

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

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

show more ...