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
Call mightFitOneOneline() on the line before the closing brace only
if it is at the level of the block.
Differential Revision: https://reviews.llvm.org/D127614
Do not remove braces if the conditional of if/for/while might not
fit on a single line even after the opening brace is removed.
Examples:
// ColumnLimit: 20
// 45678901234567890
if (a) { /* Remove. */
foo();
}
if (-b >= c) { // Keep.
bar();
}
Differential Revision: https://reviews.llvm.org/D126052
We have autogenerated pragma regions in our code
which where awkwardly broken up like this:
```
#pragma region foo(bar : hello)
```
becomes
```
#pragma region foo(bar \
: hello)
```
This fixes the problem by adding region as a keyword
and handling it the same way as pragma mark
Reviewed By: curdeius
Differential Revision: https://reviews.llvm.org/D125961
This reverts commit 50cd52d935.
It provoked regressions in C++ and ObjectiveC as described in https://reviews.llvm.org/D123676#3515949.
Reproducers:
```
MACRO_BEGIN
#if A
int f();
#else
int f();
#endif
```
```
NS_SWIFT_NAME(A)
@interface B : C
@property(readonly) D value;
@end
```
The combination of
- AlignConsecutiveAssignments.Enabled = true
- BinPackArguments = false
would result in the first continuation line of a braced-init-list being
improperly indented (missing a shift) when in a continued function call.
Indentation was also wrong for braced-init-lists continuing a
direct-list-initialization. Check for opening braced lists in
continuation and ensure that the correct shift occurs.
Fixes https://github.com/llvm/llvm-project/issues/55360
Reviewed By: curdeius
Differential Revision: https://reviews.llvm.org/D125162
Fixes https://github.com/llvm/llvm-project/issues/55407.
Given configuration:
```
UseTab: Always
PointerAlignment: Right
AlignConsecutiveDeclarations: true
```
Before, the pointer was misaligned in this code:
```
void f() {
unsigned long long big;
char *ptr; // misaligned
int i;
}
```
That was due to the fact that when handling right-aligned pointers, the Spaces were changed but StartOfTokenColumn was not.
Also, a tab was used not only for indentation but for spacing too when using `UseTab: ForIndentation` config option:
```
void f() {
unsigned long long big;
char *ptr; // \t after char
int i;
}
```
Reviewed By: owenpan
Differential Revision: https://reviews.llvm.org/D125528
If a closing brace is followed by a non-trailing comment, the
newline before the closing brace must also be removed.
Differential Revision: https://reviews.llvm.org/D125451
Reimplement the RemoveBracesLLVM feature which handles a
single-statement block that would get wrapped.
Fixes#53543.
Differential Revision: https://reviews.llvm.org/D125137
Due to how parseBracedList always stopped on the first closing angle
bracket and was used in parsing angle bracketed expression inside concept
definition, nested brackets inside concepts were parsed incorrectly.
nextToken() call before calling parseBracedList is required because
we were processing opening angle bracket inside parseBracedList second
time leading to incorrect logic after my fix.
Fixes https://github.com/llvm/llvm-project/issues/54943
Fixes https://github.com/llvm/llvm-project/issues/54837
Reviewed By: HazardyKnusperkeks, curdeius
Differential Revision: https://reviews.llvm.org/D123896
Fixes https://github.com/llvm/llvm-project/issues/54522.
This fixes regression introduced in 5e5efd8a91.
Before the culprit commit, macros in WhitespaceSensitiveMacros were correctly formatted even if their closing parenthesis weren't followed by semicolon (or, to be precise, when they were followed by a newline).
That commit changed the type of the macro token type from TT_UntouchableMacroFunc to TT_FunctionLikeOrFreestandingMacro.
Correct formatting (with `WhitespaceSensitiveMacros = ['FOO']`):
```
FOO(1+2)
FOO(1+2);
```
Regressed formatting:
```
FOO(1 + 2)
FOO(1+2);
```
Reviewed By: HazardyKnusperkeks, owenpan, ksyx
Differential Revision: https://reviews.llvm.org/D123676
The ShouldShiftBeAdded lambda checks if extra space should be
added before the wrapped part of a braced list. If the first
element of the list is wrapped, no extra space should be added.
Fixes#55161.
Differential Revision: https://reviews.llvm.org/D124956
There was some duplicate code in determineStarAmpUsage and
determinePlusMinusCaretUsage
Now a `-` or `+` following `;`, `sizeof`, `co_await`, or `delete` is
regarded as a unary operator.
Now a `*` or `&` following `case` is also a unary operator.
Reviewed By: curdeius, MyDeveloperDay, HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D121754
With D117142, we would now format
```
struct A {
#define A
void f() { a(); }
#endif
};
```
into
```
struct A {
#ifdef A
void f() {
a();
}
#endif
};
```
because we were looking for the record lbrace without skipping preprocess lines.
Fixes https://github.com/llvm/llvm-project/issues/54901.
Reviewed By: curdeius, owenpan
Differential Revision: https://reviews.llvm.org/D123737
owenca