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.
clang-format uses a heuristic to determine if a requires() is either a
requires clause or requires expression, based on what is in the
parentheses. Part of this heuristic assumed that a requires clause can
never contain a comma, however this is not the case if said comma is in
the template argument of a type.
This patch allows commas to appear in a requires clause if an angle
bracket `<` has been opened.
Fixes https://github.com/llvm/llvm-project/issues/65904
The spec doesn't allow splitting these strings and we're seeing compile
issues with splitting it.
String splitting was enabled for Verilog in
https://reviews.llvm.org/D154093.
When a statement following a case label had to be broken into multiple
lines, the continuation parts were not indented correctly.
Old:
```Verilog
case (data)
16'd0:
result = // break here
10'b0111111111;
endcase
```
New:
```Verilog
case (data)
16'd0:
result = // break here
10'b0111111111;
endcase
```
Verilog case labels and the following statements are on the same
unwrapped line due to the difficulty of identifying them. So there was a
rule in `getNewLineColumn` to add a level of indentation to the part
following the case label. However, in case the line had to be broken
again, the code at the end of the function would see that the line was
already broken with the continuation part indented, so it would not
indent it more. Now `State.FirstIndent` is changed as well for the part
following the case label, so the logic for determining when to add a
continuation indentation works.
Now. string literals in lines beginning with `export type` will not be
broken.
The case was missed in 5db201fb75e6. I don't know TypeScript. And
merging GitHub pull requests seems to be a little too easy. So it got
committed before the reviewers had a chance to find edge cases.
Dictionary literal keys and strings in TypeScript type declarations can
not be broken.
The problem was pointed out by @alexfh and @e-kud here:
https://reviews.llvm.org/D154093#4644512
Avoid unnecessarily aggressive line-breaking when using
"LambdaBodyIndentation: OuterScope" with argument bin-packing.
Differential Revision: https://reviews.llvm.org/D148131
When encountering braces, such as those of a designated initializer,
clang-format scans ahead to see what is contained within the braces. If
it found a statement, like an if-statement of for-loop, it would deem
the braces as not an initializer, but as a block instead.
However, this heuristic incorrectly included a preprocessor `#if` line
as an if-statement. This manifested in strange results and discrepancies
between `#ifdef` and `#if defined`.
With this patch, `if` is now ignored if it is preceeded by `#`.
Fixes most of https://github.com/llvm/llvm-project/issues/56685
Fixing the clang-format crash with the segmentation fault error when
formatting code with nested namespaces.
Fixes#64701.
Differential Revision: https://reviews.llvm.org/D158363
Now strings that are too long for one line in C#, Java, JavaScript, and
Verilog get broken into several lines. C# and JavaScript interpolated
strings are not broken.
A new subclass BreakableStringLiteralUsingOperators is used to handle
the logic for adding plus signs and commas. The updateAfterBroken
method was added because now parentheses or braces may be required after
the parentheses or commas are added. In order to decide whether the
added plus sign should be unindented in the BreakableToken object, the
logic for it is taken out into a separate function
shouldUnindentNextOperator.
The logic for finding the continuation indentation when the option
AlignAfterOpenBracket is set to DontAlign is not implemented yet. So in
that case the new line may have the wrong indentation, and the parts may
have the wrong length if the string needs to be broken more than once
because finding where to break the string depends on where the string
starts.
The preambles for the C# and Java unit tests are changed to the newer
style in order to allow the 3-argument verifyFormat macro. Some cases
are changed from verifyFormat to verifyImcompleteFormat because those
use incomplete code and the new verifyFormat function checks that the
code is complete.
The line in the doc was changed to being indented by 4 spaces, that is,
the default continuation indentation. It has always been the case. It
was probably a mistake that the doc showed 2 spaces previously.
This commit was fist committed as 16ccba51072b. The tests caused
assertion failures. Then it was reverted in 547bce36132a.
Reviewed By: MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D154093
Currently AlignArrayOfStructures=Left is hard coding setting Spaces to
0 for the token following the initial opening brace, but not touching
Spaces for the subsequent lines, which leads to the array being
misaligned. Additionally, it's not adding a space before the trailing
} which is generally done when Cpp11BracedListStyle=false.
I'm not exactly sure why this function needs to override the Spaces as
it seems to generally already be set to either 0 or 1 according to
the other formatting settings, but I'm going with an explicit fix where
I just force the padding to 1 when Cpp11BracedListStyle=false.
AlignArrayOfStructures=Right doesn't have any alignment problems, but
isn't adding the expected padding around the braces either, so I'm
giving that the same treatment.
Fixes#57611.
Differential Revision: https://reviews.llvm.org/D158795
(0e63f1aacc00 was reverted by 7590b7657004 due to a crash.)
Annotate constructor/destructor names as FunctionDeclarationName.
Fixes#63046.
Differential Revision: https://reviews.llvm.org/D157963
* [clang-format] rename the file comments to match the file name
* [clang-format] rename the file comments to match the file name
* Remove extraneous space
* [clang-format] NFC remove EOF
---------
Co-authored-by: paul_hoad <paul_hoad@amat.com>
Now strings that are too long for one line in C#, Java, JavaScript, and
Verilog get broken into several lines. C# and JavaScript interpolated
strings are not broken.
A new subclass BreakableStringLiteralUsingOperators is used to handle
the logic for adding plus signs and commas. The updateAfterBroken
method was added because now parentheses or braces may be required after
the parentheses or commas are added. In order to decide whether the
added plus sign should be unindented in the BreakableToken object, the
logic for it is taken out into a separate function
shouldUnindentNextOperator.
The logic for finding the continuation indentation when the option
AlignAfterOpenBracket is set to DontAlign is not implemented yet. So in
that case the new line may have the wrong indentation, and the parts may
have the wrong length if the string needs to be broken more than once
because finding where to break the string depends on where the string
starts.
The preambles for the C# and Java unit tests are changed to the newer
style in order to allow the 3-argument verifyFormat macro. Some cases
are changed from verifyFormat to verifyImcompleteFormat because those
use incomplete code and the new verifyFormat function checks that the
code is complete.
The line in the doc was changed to being indented by 4 spaces, that is,
the default continuation indentation. It has always been the case. It
was probably a mistake that the doc showed 2 spaces previously.
Reviewed By: MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D154093
Fixes a long-standing bug that erroneously placed function arguments on a
new line despite all arguments being able to fit on the same line.
The original diff that introduced the bug implemented behaviour that pushed
the first argument to a function onto a new line under certain circumstances
relating passing lambdas as arguments.
This behaviour was implemented in TokenAnnotator::mustBreakBefore() which
meant the code lacked the necessary context to figure out whether subsequent
arguments might be able to all fit on one line. As such, I've moved the
implementation to ContinuationIndenter and, instead of forcing a line break
at the first argument in all cases, we now allow the OptimizingLineFormatter
to consider placing the first argument on the same line as the function call
but don't allow further line breaks in this case.
The end result is that either the first argument must go on a new line (as
before) or all arguments must be put on the current line.
Closes#44486.
Differential Revision: https://reviews.llvm.org/D156259
