The colon in a constructor's initializer list triggers the inlining of a
nested block as if it was a conditional operator expression. This
prevents line breaks under certain circumstances when the initializer
list contains braced initializers, which in turn prevents the line
formatter from finding a solution.
In this commit we exclude colons that are a constructor initializer
colon from consideration of nested block inlining.
Fixes#97242.
Fixes#81822.
In clang-format, multiline templates have the `>` on the same line as
the last parameter:
```c++
template <
typename Foo,
typename Bar>
void foo() {
```
I would like to add an option to put the `>` on the next line, like
this:
```c++
template <
typename Foo,
typename Bar
>
void foo() {
```
An example of a large project that uses this style is NVIDIA's CUTLASS,
here is an example:
https://github.com/NVIDIA/cutlass/blob/main/include/cutlass/epilogue/dispatch_policy.hpp#L149-L156
My reasoning is that it reminds me of this style of braces:
```c++
if (foo()) {
bar();
baz();}
```
Most people agree this is better:
```c++
if (foo()) {
bar();
baz();
}
```
---------
Co-authored-by: Owen Pan <owenpiano@gmail.com>
Near the ColumnLimit a break could be inserted before a right parens
with BlockIndent without a break after the matching left parens. Avoid
these hanging right parens by disallowing breaks before right parens
unless there was a break after the left parens.
Fixes#103306
* Convert `ReflowComments` from boolean into a new `enum` which can take
on the value `RCS_Never`, `RCS_IndentOnly`, or `RCS_Always`. The first
one is equivalent to the old `false`, the third one is `true`, and the
middle one means that multiline comments should only have their
indentation corrected, which is what Doxygen users will want.
* Preserve backward compatibility while parsing `ReflowComments`.
ccae7b461be339e717d02f99ac857cf0bc7d17f improved handling for nested
calls, but this resulted in a lot of changes near `new` expressions.
This patch tries to restore previous behavior around new expressions, by
treating them as simple functions, which seem to align with the concept.
Fixes https://github.com/llvm/llvm-project/issues/105133.
Address #101550 by adding OwnLineWithBrace option for RequiresClausePosition. This permits placing a following '{' on the same line as the requires clause.
Thus, instead of:
```
bool Foo ()
requires(true)
{
return true;
}
```
we have:
```
bool Foo ()
requires(true) {
return true;
}
```
If the function body is empty, we'll get:
```
bool Foo ()
requires(true) {}
```
I attempted to get a line break between the open and close braces, but
failed. Perhaps that's fine -- it's rare and only happens in the empty
body case.
By default, clang-format packs binary operations, but it may be
desirable to have compound operations be on individual lines instead of
being packed.
This PR adds the option `BreakBinaryOperations` to break up large
compound binary operations to be on one line each.
This applies to all logical and arithmetic/bitwise binary operations
Maybe partially addresses #79487 ?
Closes#58014Closes#57280
Fixes#55731
The reported formatting problems were related to ignoring deep nesting
of "simple" functions (causing #54808) and to allowing the trailing
annotation to become separated from the closing parens, which allowed a
break to occur between the closing parens and the trailing annotation.
The fix for the nesting of "simple" functions is to detect them more
carefully. "Simple" was defined in a comment as being a single
non-expression argument. I tried to stay as close to the original intent
of the implementation while fixing the various bad formatting reports.
In the process of fixing these bugs, some latent bugs were discovered
related to how JavaScript Template Strings are handled. Those are also
fixed here.
---------
Co-authored-by: Owen Pan <owenpiano@gmail.com>
I'm planning to remove StringRef::equals in favor of
StringRef::operator==.
- StringRef::operator==/!= outnumber StringRef::equals by a factor of
24 under clang/ in terms of their usage.
- The elimination of StringRef::equals brings StringRef closer to
std::string_view, which has operator== but not equals.
- S == "foo" is more readable than S.equals("foo"), especially for
!Long.Expression.equals("str") vs Long.Expression != "str".
This reverts commit b92d6dd704d789240685a336ad8b25a9f381b4cc. See
github.com/llvm/llvm-project/commit/b92d6dd704d7#commitcomment-139992444
We should use a tool like Visual Studio to clean up the headers.
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
