llvm-project/clang/lib/Format/TokenAnnotator.cpp:2707:43:
error: lambda capture 'this' is not used [-Werror,-Wunused-lambda-capture]
auto IsQualifiedPointerOrReference = [this](FormatToken *T) {
^~~~
1 error generated.
When reconstructing lines from a macro expansion, make sure that lines
at different levels in the expanded code get indented correctly as part
of the macro argument.
The while loop on line 3814 can cause a segmentation fault getting the
Next field on a nullptr. This is because further down, on line 3823,
there is another for loop, which assigns Tok to Tok->Next in its
initializer. This for loop has a condition to check if the result of
that isn't null. If it is, the loop is skipped and we drop back out to
the outer loop, except, now Tok is null, and we try to dereference it
without checking first.
This patch adds a defensive check that returns if Tok->Next is null
before we make it to the second for loop.
Fixes https://github.com/llvm/llvm-project/issues/82328
---------
Co-authored-by: Owen Pan <owenpiano@gmail.com>
Running clang-format on the following input
```
int lambdas() {
return [&] {
return [&] {
return [&] {
return [&] {
return [&] {
return [&] {
return [&] { return 3; } ();
} (); } (); } (); } (); } (); } (); }
```
will finish instantly if you pass clang-format a .cpp input with this
content, but hang for tens of seconds if you pass the same via stdin
or a .h file.
Adding some debug statements showed that guessIsObjC was getting called
tens of millions of times in a manner that scales very rapidly with the
amount of nesting (if clang-format just takes a few seconds with that
input passed on stdin, try adding a couple more levels of nesting).
This change moves the recursive guessIsObjC call one level of nesting
out of an inner loop whose iterations don't affect the input to the
recursive call. This resolves the performance issue.
Authored-by: davidvc1 and Uran198
Differential Revision: https://reviews.llvm.org/D114837
Differential Revision: https://reviews.llvm.org/D47515
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
Changes the option to BreakAfterReturnType option, with a more relevant
name, deprecating and replacing AlwaysBreakAfterReturnType.
Following up on #78010.
This implements the annotation of the values in TableGen.
The main changes are,
- parseTableGenValue(), the simplified parser method for the syntax of
values.
- modified consumeToken() to parseTableGenValue in 'if', 'assert' and
after '='.
- modified parseParens() to call parseTableGenValue inside.
- modified parseSquare() to to call parseTableGenValue inside, with
skipping separator tokens.
- modified parseAngle() to call parseTableGenValue inside, with skipping
separator tokens.
Resolves#27008, #39735, #53013, #63619.
Hello, this PR adds the MainIncludeChar option to clang-format, allowing
to select which include syntax must be considered when searching for the
main header: quotes (`#include "foo.hpp"`, the default), brackets
(`#include <foo.hpp>`), or both.
The lack of support for brackets has been reported many times, see the
linked issues, so I am pretty sure there is a need for it :)
A short note about why I did not implement a regex approach as discussed
in #53013: while a regex would have allowed many extra ways to describe
the main header, the bug descriptions listed above suggest a very simple
need: support brackets for the main header. This PR answers this needs
in a quite simple way, with a very simple style option. IMHO the feature
space covered by the regex (again, for which there is no demand :)) can
be implemented latter, in addition to the proposed option.
The PR also includes tests for the option with and without grouped
includes.
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
If clang-format is not sure whether a `requires` keyword starts a
requires clause or a requires expression, it looks ahead to see if any
token disqualifies it from being a requires clause. Among these tokens
was `decltype`, since it fell through the switch.
This patch allows decltype to exist in a require clause.
I'm not 100% sure this change won't have repercussions, but that just
means we need more test coverage!
Fixes https://github.com/llvm/llvm-project/issues/78645
Adds the support for tokens that have forms like unary operators.
- bang operators: `!name`
- cond operator: `!cond`
- numeric literals: `+1`, `-1`
cond operator are one of bang operators but is distinguished because it has very specific syntax.
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.
