before, with the options `AlignConsecutiveDeclarations` and
`AlignConsecutiveAssignments` enabled
```C++
veryverylongvariablename = somethingelse;
shortervariablename = anotherverylonglonglongvariablename + //
somevariablethatwastoolongtofitonthesamerow;
double i234 = 0;
auto v = false ? type{}
: type{
1,
};
```
after
```C++
veryverylongvariablename = somethingelse;
shortervariablename = anotherverylonglonglongvariablename + //
somevariablethatwastoolongtofitonthesamerow;
double i234 = 0;
auto v = false ? type{}
: type{
1,
};
```
Fixes#126873.
Fixes#57612.
Previously, the part for determining whether aligning a line should move
the next line relied on having a pair of tokens such as parentheses
surrounding both lines. There are often no such tokens. For example in
the first block above. This patch removes the requirement for those
tokens.
Now the program keeps track of how the position is calculated. The
alignment step moves the next line if its position is based on a column
to the right of the token that gets aligned.
The column that the position of the line is based on is more detailed
than the `IsAligned` property that the program used before this patch.
It enables the program to handle cases where parts that should not
usually move with the previous line and parts that should are nested
like in the second block above. That is why the patch uses it instead of
fake parentheses.
Replace the `AlwaysBreak` and `BlockIndent` suboptions of
`AlignAfterOpenBracket` with new style options `BreakAfterOpenBracket*`
and `BreakBeforeCloseBracket*` for `*` in `BracedList` for braced list
initializers, `if` for if conditional statements, `Loop` for loop
control statements (for/while), `Switch` for switch statements, and
`Function` for function calls/declarations/definitions.
Deprecates `AlwaysBreak` and `BlockIndent`.
Fixes#67738Fixes#79176Fixes#80123Fixes#151844
Line comments in preprocessor directives were incorrectly marked as
continuing the directive, causing clang-format to add backslashes after
them on repeated runs. Backslashes appended after line comments in this
way do not continue the PP directive because the following line would
also become part of the comment.
Fix by unsetting `InPPDirective` in
`WhitespaceManager::replaceWhitespace` for line comments in two places:
when breaking lines and when formatting tokens on the same line. This
stops the spurious backslash insertion for both standalone line comments
after PP directives and trailing line comments after macro bodies.
Fixes https://github.com/llvm/llvm-project/issues/164282.
Signed-off-by: Ruoyu Zhong <zhongruoyu@outlook.com>
Fixes http://llvm.org/PR55487 (#55487)
The code did not match the documentation about Cpp11BracedListStyle.
Changed handling of comments after opening braces, which are supposedly
function call like to behave exactly like their parenthesis counter
part.
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
