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
There are two parts to this fix:
- Annotate the paren after an AttributeMacro as an AttributeLParen.
- Treat an AttributeMacro-without-paren the same as one with a paren.
I added a new test-case to differentiate a macro that is or is-not an
AttributeMacro; also handled whether ColumnLimit is set to infinite (0) or a
finite value, as part of this patch is in ContinuationIndenter.
Closes#68722.
Differential Revision: https://reviews.llvm.org/D145262
Reland 6a621ed8e4cb which failed on Windows but not macOS.
The failures were caused by moving the annotation of the children from the
top to the bottom of TokenAnnotator::annotate(), resulting in invalid lines
including incomplete ones being skipped.
After annotating constructors/destructors as FunctionDeclarationName in
commit 08630512088, we have seen several issues because ctors/dtors had
been treated differently than functions in aligning, wrapping, and
indenting.
This patch annotates ctors/dtors as CtorDtorDeclName instead and would
effectively revert commit 0468fa07f87f, which is obsolete now.
Fixed#67903.
Fixed#67907.
Don't remove the outermost parentheses surrounding a return statement
expression when inside a function/lambda that has the decltype(auto)
return type.
Fixed#67892.
By default, OuterScope aligns lambdas to the beginning of the current
line. This makes sense for most types of statements within code blocks
but leads to unappealing and misleading indentation for lambdas within
constructor initializers.
