This includes TT_MacroBlockBegin and TT_MacroBlockEnd as well.
We can no longer use MatchingParen of FormatToken as an indicator
to mark optional braces. Instead, we directly set Optional of an
l_brace first and reset it later if it turns out that the braces
are not optional.
Also added a test case for deeply nested loops.
Differential Revision: https://reviews.llvm.org/D139257
For comments that start after a new line, currently, the comments are
being indented. This happens because the OriginalWhitespaceRange
considers newlines on the range. Therefore, when AlignTrailingComments:
Kind: Leave, deduct the number of newlines before the token to calculate
the number of spaces for trailing comments.
Fixes#59203.
Differential Revision: https://reviews.llvm.org/D139029
The unused variable fix also remove the test output of the tokens
that do not match, making debugging tests harder. Undo the semantic
changes of the build fix.
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 / 92b397fb9d)
Fixes https://github.com/llvm/llvm-project/issues/55733
Reviewed By: HazardyKnusperkeks, owenpan
Differential Revision: https://reviews.llvm.org/D137223
I'm not exactly sure what the intent of that section of
`spaceRequiredBetween` is doing, it seems to handle templates and <<,
but the part which adds spaces before parens is way later, as part
of `spaceRequiredBeforeParens`.
Fixes https://github.com/llvm/llvm-project/issues/58821
Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D137474
I want to reduce the size of ForatTest.cpp with its still wopping 25k
lines it is a burden on the compiler and editor (mine is clangd
powered).
This are tests which are really serving a different purpose than
formatting.
I've copied the code and made the following changes:
- Dropped the ; at the end of some macros, all macro "invocations"
already have their own ;.
- Dropped the _F, we don't need a fxiture here.
Differential Revisison: https://reviews.llvm.org/D137823
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
If true, colons in ASM parameters will be placed after line breaks.
true:
asm volatile("string",
:
: val);
false:
asm volatile("string", : : val);
Differential Revision: https://reviews.llvm.org/D91950
I've:
- Sorted the members of FormatStyle alphabetical. The enums and structs
are kept close to the member.
- Sorted the yaml io functions, based on the type they operate on.
- Sorted the initializers in getLLVMStyle(), except that penalities are
kept at the end.
- Sorted the io of FormatStyle, this changes the --dump-config behavior.
- Moved the deprecated options into the only input case, this also
changes --dump-config, it does not put the not directly used options
in the .clang-format anymore.
- Sorted the comparisons in operator==.
- Added WhiteSpaceMacros in operator==, I've not actively looked if all
other members are compared.
- This showed flawed tests (or in my opinion a flawed io operation, but
that is another discussion and change).
Differential Revision: https://reviews.llvm.org/D137409
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
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
Without the patch UnwrappedLineFormatter::analyzeSolutionSpace just ran
out of possible formattings and would put everything just on one line.
The problem was that the the line break was forbidden, but putting the
conditional colon on the same line is also forbidden.
Differential Revision: https://reviews.llvm.org/D135918
Previously the program would crash on this input:
```
#else
#if X
```
The problem was that in `parsePPElse`, `PPBranchLevel` would be
incremented when the first `#else` gets parsed, but `PPLevelBranchCount`
and `PPLevelBranchIndex` would not be updated together.
I found the problem when working on D135740.
Differential Revision: https://reviews.llvm.org/D135972
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
Adds an option whether requires clause body should be aligned with
the `requires` keyword.
This option is now the default, both without configuration and in LLVM
style.
Fixes https://github.com/llvm/llvm-project/issues/56283
Differential Revision: https://reviews.llvm.org/D129443
Co-authored-by: Emilia Dreamer <emilia@rymiel.space>
Currently, we parse lines inside of a compiler `#pragma` the same way we
parse any other line. This is fine for some cases, like separating
expressions and adding proper spacing, but in others it causes some poor
results from miscategorizing some tokens.
For example, the OpenMP offloading uses certain clauses that contain
special characters like `map(tofrom : A[0:N])`. This will be formatted
poorly as it will be split between lines on the first colon.
Additionally the subscript notation will lead to poor spacing. This can
be seen in the OpenMP tests as the automatic clang formatting with
inevitably ruin the formatting.
For example, the following contrived example will be formatted poorly.
```
#pragma omp target teams distribute collapse(2) map(to: A[0 : M * K]) \
map(to: B[0:K * N]) map(tofrom:C[0:M*N]) firstprivate(Alpha) \
firstprivate(Beta) firstprivate(X) firstprivate(D) firstprivate(Y) \
firstprivate(E) firstprivate(Z) firstprivate(F)
```
This results in this when formatted, which is far from ideal.
```
#pragma omp target teams distribute collapse(2) map(to \
: A [0:M * K]) \
map(to \
: B [0:K * N]) map(tofrom \
: C [0:M * N]) firstprivate(Alpha) \
firstprivate(Beta) firstprivate(X) firstprivate(D) firstprivate(Y) \
firstprivate(E) firstprivate(Z) firstprivate(F)
```
This patch seeks to improve this by adding extra logic where the parsing goes
awry. This is primarily caused by the colon being parsed as an inline-asm
directive and the brackes an objective-C expressions. Also the line gets
indented every single time the line is dropped.
This doesn't implement true parsing handling for OpenMP statements.
Reviewed By: HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D136100
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 f1f267b447.
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
This solves the issue where a case statement inside a macro greedily
adds preprocessor lines such as #include to the macro even if they
are not a part of the macro to begin with.
Fixes#58214.
Differential Revision: https://reviews.llvm.org/D135422
Fixes: https://github.com/llvm/llvm-project/issues/58217
This change is to remove extraneous and unnecessary ';' from after a function definition, its off by default and carries the same "code modification" warning as some of our other code manipulating changes.
Reviewed By: HazardyKnusperkeks, owenpan
Differential Revision: https://reviews.llvm.org/D135466
Different loop termination conditions resulted in confusion of whether
*Offset was intended to be inside or outside the token.
This ultimately led to constructing an out-of-range SourceLocation.
Fix by making Offset consistently point *after* the token.
Differential Revision: https://reviews.llvm.org/D135356
When a compound requirement is too long to fit onto a single line, the
braces are split apart onto separate lines, and the contained expression
is indented. However, this indentation would also apply to the closing
brace and the trailing return type requirement thereof.
This was because the indentation level was being restored after all
trailing things were already read
With this change, the initial level of the opening brace is set before
attempting to read any trailing return type requirements
Fixes https://github.com/llvm/llvm-project/issues/57108
Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D134626
Summary:
clang-format makes multiple passes when #if/#else preprocessor blocks are found. It will make
one pass for normal code and code in the #if block, and then it will make another pass for just
the code in #else blocks. This often results in invalid alignment inside the else blocks because
they do not have any scope or indentAndNestingLevel context from their surrounding tokens/lines.
This patch remedies that by caching any initial indentAndNestingLevel from a second pass and
not breaking/returning early when a scope change is detected.
Fixes#36070
Reviewers: HazardyKnusperkeks, MyDeveloperDay
Tags: clang, clang-format
Differential Revision: https://reviews.llvm.org/D134042
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
`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
Working in a mixed environment of both vscode/vim with a team configured prettier configuration, this can leave clang-format and prettier fighting each other over the formatting of arrays, both simple arrays of elements.
This review aims to add some "control knobs" to the Json formatting in clang-format to help align the two tools so they can be used interchangeably.
This will allow simply arrays `[1, 2, 3]` to remain on a single line but will break those arrays based on context within that array.
Happy to change the name of the option (this is the third name I tried)
Reviewed By: HazardyKnusperkeks, owenpan
Differential Revision: https://reviews.llvm.org/D133589
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
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
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
Fixes https://github.com/llvm/llvm-project/issues/57539
Previously things outside of `#if` blocks were parsed as if only the
first branch of the conditional compilation branch existed, unless the
first condition is 0. In that case the outer parts would be parsed as
if nothing inside the conditional parts existed. Now we use the second
conditional branch if the first condition is 0.
Reviewed By: owenpan
Differential Revision: https://reviews.llvm.org/D133647
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
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
Owen Pan