Fix an issue where the lambda body left brace could sometimes fail to be
wrapped when AllowShortLambdasOnASingleLine is enabled.
Now, when BraceWrapping.BeforeLambdaBody is enabled, if the brace is not
wrapped, we prevent breaks in the lambda body.
Resolves#81845
new
```C
while (_Generic(x, //
long: x)(x) > x) {
}
while (_Generic(x, //
long: x)(x)) {
}
```
old
```C
while (_Generic(x, //
long: x)(x) > x) {
}
while (_Generic(x, //
long: x)(x)) {
}
```
In the first case above, the second line previously aligned to the open
parenthesis. The 4 spaces did not get added by the fallback line near
the end of getNewLineColumn because there was already some indentaton.
Now the spaces get added explicitly.
In the second case above, without the fake parentheses, the second line
did not respect the outer parentheses, because the LastSpace field did
not get set without the fake parentheses. Now the indentation of the
outer level is used instead.
The RTBS_None option in Clang-format avoids breaking after a short
return type.
However, there was an issue with the behaviour in that it wouldn't take
the leading indentation of the line into account.
This meant that the behaviour wasn't applying when intended.
In order to address this situation without breaking the existing
formatting, RTBS_None has been deprecated.
In its place are two new options for AlwaysBreakAfterReturnType.
The option RTBS_Automatic will break after the return type based on
PenaltyReturnTypeOnItsOwnLine.
The option RTBS_ExceptShortType will take the leading indentation into
account and prevent breaking after short return types.
This allows the inconsistent behaviour of RTBS_None to be avoided and
users to decide whether they want to allow breaking after short return
types or not.
Resolves#78010
A bug with BlockIndent prevents line breaks within if (and else if)
clauses.
While fixing this bug, it appears that AlignAfterOpenBracket is not
designed to work with loop and if statements, but AlwaysBreak works on
if clauses. The documentation and tests are not clear on whether or not
this behavior is intended.
This PR preserves the `AlwaysBreak` behavior on `if` clauses without
supporting `BlockIndent` on `if` clauses to avoid regressions while
fixing the bug.
It may be reasonable to create an explicit option for alignment of if
(and loop) clauses intentionally for both `AlwaysBreak` and
`BlockIndent`
Fixes#54663.
Migrated from Differential Revision: https://reviews.llvm.org/D154755
See more discussion there. Addressed last open comment from the rev
about refactoring the complex conditional logic involved with the
`AlignAfterOpenBracket` line break behavior.
clang-format has logic to align declarations of multiple variables of
the same type, aligning them at the equals sign. This logic is applied
in for loops as well. However, this alignment logic also erroneously
affected the equals signs of designated initializers.
This patch forbids alignment if the token 2 tokens back from the equals
sign is a designated initializer period.
Fixes https://github.com/llvm/llvm-project/issues/73902
Fixesllvm/llvm-project#62904
`AlignArrayOfStructures: Left` combined with `SpacesInParentheses: true`
causes the first cell of every row to have 1 additional space.
We were only setting the first cell of the first row to be against the
left brace, now every row will be against the left brace.
This addresses a problem with formatting attributes. Some context:
- eaff083035c8 changed `isStartOfName` to fix problems inside
`#pragma`s, but this behavior changed formatting of attribute macros in
an undesirable way.
- efeb546865c233dfa7706ee0316c676de9f69897 changed Google format style
to fix some widely used attributes.
Instead of changing the format style, this commit specializes behavior
introduced in eaff083035c8 to `#pragma`s. This seems to work well in
both cases.
Also update the test with two `GUARDED_BY` directives. While the
formatting after efeb546865c233dfa7706ee0316c676de9f69897 seems better,
this case is rare enough to not warrant the extra complexity. We are
reverting it back to the state it had before
efeb546865c233dfa7706ee0316c676de9f69897.
---------
Co-authored-by: Owen Pan <owenpiano@gmail.com>
Done as requested in llvm/llvm-project#77045
I have changed the test a bit, because since the root problem was fixed,
the original test would possibly never crash.
Fixesllvm/llvm-project#76716
Fixes parsing of `[0]{}`. Before this patch it was begin parsed as a
lambda, now it is correctly parsed as a designator initializer.
Function pointers are detected as a type of declaration using
FunctionTypeLParen. They are aligned based on rules for
AlignConsecutiveDeclarations. When a function pointer is on the
right-hand side of an assignment, the alignment of the function pointer
can result in excessive whitespace padding due to the ordering of
alignment, as the alignment processes a line from left-to-right and
first aligns the declarations before and after the assignment operator,
and then aligns the assignment operator. Injection of whitespace by
alignment of declarations after the equal sign followed by alignment of
the equal sign results in the excessive whitespace.
Fixes#68079.
If there are possible column formats, but they weren't selected because
they don't fit within remaining characters for the current path then
applying severe penalty to induce column layout by selection of a
different path seems fair.
But if due to style configuration or what the input code is, there are
no possible column formats, different paths aren't going to have column
layouts. Seems wrong to apply the severe penalty to induce column
layouts if there are none available.
It just causes selection of sub-optimal paths, e.g. get bad formatting
when brace initializers are used inside lambda bodies.
Fixes#56350
This restores a subset of functionality that was forego in
d68826dfbd987377ef6771d40c1d984f09ee3b9e.
Streaming multiple string literals is rare enough in practice, hence
that change makes sense in general. But it seems people were
incidentally relying on this for having line breaks after string
literals that ended with `\n`.
This patch tries to restore that behavior to prevent regressions in the
upcoming LLVM release, until we can implement some configuration based
approach as proposed in https://github.com/llvm/llvm-project/pull/69859.
We have found that 199fc973ced20016b04ba540cf63a1d4914fa513 regresses
formatting of our codebases because we do not properly configure the
names of attribute macros.
`GUARDED_BY` and `ABSL_GUARDED_BY` are very commoon in Google codebases
so it is reasonable to include them by default to avoid the need for
extra configuration in every Google repository.
This would also fix the overlapping replacements below:
```
$ clang-format
a(
#else
#endif
) = []() {
)}
The new replacement overlaps with an existing replacement.
New replacement: <stdin>: 38:+7:"
"
Existing replacement: <stdin>: 38:+7:" "
```
Fixed#73487.
Function and variable names are not detected when there is a
__attribute__((x)) preceding the name.
Fixes#64137.
Differential Revision: https://reviews.llvm.org/D156370
This patch addresses some examples of bad formatting in Clang. The following commit contains only changes suggested by clang-format: 21689b56d1.
I believe it's a net negative on readability, with a couple of particularly bad cases. Highlights:
```diff
- [[clang::preferred_type(bool)]]
- mutable unsigned CachedLocalOrUnnamed : 1;
+ [[clang::preferred_type(bool)]] mutable unsigned CachedLocalOrUnnamed : 1;
```
```diff
- [[clang::preferred_type(TypeDependence)]]
- unsigned Dependence : llvm::BitWidth<TypeDependence>;
+ [[clang::preferred_type(TypeDependence)]] unsigned Dependence
+ : llvm::BitWidth<TypeDependence>;
```
```diff
- [[clang::preferred_type(ExceptionSpecificationType)]]
- unsigned ExceptionSpecType : 4;
+ [[clang::preferred_type(
+ ExceptionSpecificationType)]] unsigned ExceptionSpecType : 4;
```
Style guides doesn't appear to have an opinion on this matter.
clang-format brace wrapping did not take requires into consideration,
compound requirements will be affected by BraceWrapping.AfterFunction.
Closes#59412.
Differential Revision: https://reviews.llvm.org/D139834
Add AfterPlacementNew option to SpaceBeforeParensOptions to have more
control on placement new expressions.
Fixes#41501
Relates to #54703
Differential Revision: https://reviews.llvm.org/D127270
