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
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
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
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
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
When the opening brace of a control statement block is wrapped, we
must check the previous line to determine whether to try to merge
the block.
Fixes#38639.
Fixes#48007.
Fixes#57421.
Differential Revision: https://reviews.llvm.org/D133093
If the style wraps control statement braces, the opening braces
should be inserted after the trailing comments if present.
Fixes#57419.
Differential Revision: https://reviews.llvm.org/D132905
When an l_brace is wrapped and the line above it ends with a
comment, the annotator adds ColumnLimit to the TotalLength of the
l_brace, so the actual column position of the l_brace must be
adjusted accordingly.
Fixes#57376.
Differential Revision: https://reviews.llvm.org/D132805
There's no a space symbol between trailing return type `auto` and left brace `{`.
The simpliest examles of code to reproduce the issue:
```
[]() -> auto {}
```
and
```
auto foo() -> auto {}
```
Depends on D130299
Reviewed By: HazardyKnusperkeks, curdeius, owenpan
Differential Revision: https://reviews.llvm.org/D130417
After b646f09555,
the added regression test started being formatted as-if the
multiplication `*` was a pointer. This adapts the heuristic to
distinguish between these two cases.
Reviewed By: jackhong12, curdeius, HazardyKnusperkeks, owenpan
Differential Revision: https://reviews.llvm.org/D129771
When removing an r_brace that is the first token of an annotated line, if the
line above ends with a line comment, clang-format generates invalid code by
merging the tokens after the r_brace into the line comment.
Fixes#56488.
Differential Revision: https://reviews.llvm.org/D129742
Break after a constructor initializer colon only if it's not followed by a
comment on the same line.
Fixes#41128.
Fixes#43246.
Differential Revision: https://reviews.llvm.org/D129057
Owen Pan