out for regressions.
Clang Format is detecting a nested scope followed by another open brace
as a braced initializer list due to incorrectly thinking it's matching a
braced initializer at the end of a constructor initializer list which is
followed by the body open brace.
Unfortunately, UnwrappedLineParser isn't doing a very detailed parse, so
it's not super straightforward to distinguish these cases given the
current structure of calculateBraceTypes. My current hypothesis is that
these can be disambiguated by looking at the token preceding the
l_brace, as initializer list parameters will be preceded by an
identifier, but a scope block generally will not (barring the MACRO
wildcard).
To this end, I am adding tracking of the previous token to the LBraceStack
to help scope this particular case.
TokenAnnotatorTests cherry picked from https://reviews.llvm.org/D150452.
Fixes#33891.
Fixes#52911.
Differential Revision: https://reviews.llvm.org/D150403
When in ColumnLimit 0, the formatter looks for MustBreakBefore in the
line in order to check if a line is allowed to be merged onto one line.
However, since MustBreakBefore is really a property of the gap between
the token and the one previously, I belive the check is erroneous in
checking all the tokens in a line, since whether the previous line ended
with a forced line break should have no effect on whether the current
line is allowed to merge with the next one.
This patch changes the check to skip the first token in
`LineJoiner.containsMustBreak`.
This patch also changes a test, which is not ideal, but I believe the
test also suffered from this bug. The test case in question sets
AllowShortFunctionsOnASingleLine to "Empty", but the empty function in
said test case isn't merged to a single line, because of the very same
bug this patch fixes.
Fixes https://github.com/llvm/llvm-project/issues/62721
Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D150614
This check is similar to the right paren check right below it, but it
doesn't need the overloaded operator check.
This patch prevents brace-initialized objects that are being compared
from being mis-annotated as template parameters.
Fixes https://github.com/llvm/llvm-project/issues/57004
Reviewed By: owenpan, MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D150629
Since 3.8 or earlier, clang-format has been lumping all #else, #elif,
etc blocks together when doing whitespace replacements and causing
consecutive alignments across #else blocks.
Commit c077975 partially addressed the problem but also triggered
"regressions".
This patch fixes the root cause of the problem and "reverts" c077975
(except for the unit tests).
Fixes#36070.
Fixes#55265.
Fixes#60721.
Fixes#61498.
Differential Revision: https://reviews.llvm.org/D150057
There doesn't seem to be an issue on GitHub. But previously, a space
would be inserted before the goto colon in the code below.
switch (x) {
case 0:
goto_0: {
action();
break;
}
}
Previously, the colon following a goto label would be annotated as
`TT_InheritanceColon`. A goto label followed by an opening brace
wasn't recognized. It is easy to add another line to have
`spaceRequiredBefore` function recognize the case, but I believed it
is more proper to avoid doing the same thing in `UnwrappedLineParser`
and `TokenAnnotator`. So now the label colons would be labeled in
`UnwrappedLineParser`, and `spaceRequiredBefore` would rely on that.
Previously we had the type `TT_GotoLabelColon` intended for both goto
labels and case labels. But since handling of goto labels and case
labels differ somewhat, I split it into separate types for goto and
case labels.
This patch doesn't change the behavior for case labels. I added the
lines annotating case labels because they would previously be
mistakenly annotated as `TT_InheritanceColon` just like goto labels.
And since I added the annotations, the checks for the `case` and
`default` keywords in `spaceRequiredBefore` are not necessary anymore.
Reviewed By: MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D148484
The option allows users to specify how many columns to use to indent
the contents of initializer lists.
Closes#51070.
Differential Revision: https://reviews.llvm.org/D146101
When using BraceWrapping.AfterClass or BraceWrapping.AfterStruct, the
token annotator relies on the first token of the line to determine if
we're dealing with a struct or class, however, this check is faulty if
it's actually a function with an elaborated struct/class return type, as
is common in C.
This patch skips the check if the brace is already annotated as
FunctionLBrace, in which case we already know it's a function and should
be treated as such.
Fixes https://github.com/llvm/llvm-project/issues/58527
Reviewed By: HazardyKnusperkeks, owenpan
Differential Revision: https://reviews.llvm.org/D146281
The trailing return type arrow checker verifies that a declaration is
being parsed, however, this isn't true when inside of macros.
It turns out the existence of the auto keyword is enough to make
sure that we're dealing with a trailing return type, and whether we're
in a declaration doesn't matter.
Fixes https://github.com/llvm/llvm-project/issues/47664
Reviewed By: HazardyKnusperkeks, owenpan
Differential Revision: https://reviews.llvm.org/D141811
The noexcept specifier and explicit specifier can optionally include a
boolean expression to make these specifiers apply conditionally,
however, clang-format didn't set the context for the parenthesized
content of these specifiers, meaning they inherited the parent context,
which usually isn't an expressions, leading to misannotated binary
operators.
This patch applies expression context to the content of these
specifiers, making them similar to the static_assert keyword.
Fixes https://github.com/llvm/llvm-project/issues/44543
Reviewed By: owenpan, MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D146284
The token annotator doesn't annotate the template opener and closer
as such if they enclose an overloaded operator. This causes the
space between the operator and the closer to be removed, resulting
in invalid C++ code.
Fixes#58602.
Differential Revision: https://reviews.llvm.org/D143755
Previously, the token annotator would get confused and annotate a member
function's ref qualifier as a binary operator, if said function also had
a requires clause after it.
This patch accounts for that, treating requires clauses more similarly
to `noexcept`, which also comes after the ref qualifier.
Fixes https://github.com/llvm/llvm-project/issues/61270
Reviewed By: HazardyKnusperkeks, owenpan
Differential Revision: https://reviews.llvm.org/D145656
The l_brace of class/struct/union was incorrectly annotated as
TT_FunctionLBrace in the presence of attributes. This in turn
would cause the RemoveSemicolon option to remove the semicolon
at the end of the declaration, resulting in invalid code being
generated.
Fixes#61188.
Differential Revision: https://reviews.llvm.org/D145344
Pull out common base class for formatting unit tests, removing duplicate
code that accumulated over the years.
Pull out macro expansion test into its own test file.
The patch in D136100 added custom handling for pragmas to assist in
formatting OpenMP clauses correctly. One of these changes added extra
indentation. This is desirable for OpenMP pragmas as they are several
complete tokens that would otherwise we on the exact same line. However,
this is not desired for the other pragmas.
This solution is extremely hacky, I'm not overly familiar with the
`clang-format` codebase. A better solution would probably require
actually parsing these as tokens, but I just wanted to propose a
solution.
Fixes https://github.com/llvm/llvm-project/issues/59473
Reviewed By: HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D144884
The previous version set the indentation directly using IndentForLevel,
however, this has a few caveats, namely:
* IndentForLevel applies to all scopes of the entire program being
formatted, but this indentation should only be adjusted for scopes
of namespaces.
* The method it used only set the correct indent amount if one wasn't
already set for a given level, meaning it didn't work correctly if
anything with indentation preceded a namespace keyword. This
includes preprocessing directives if using IndentPPDirectives.
This patch instead reduces the Level of all lines within namespaces
which are compacted by CompactNamespaces. This means they will get
correct indentation using the normal process.
Fixes https://github.com/llvm/llvm-project/issues/60843
Reviewed By: owenpan, MyDeveloperDay, HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D144296
Add configuration to specify macros.
Macros will be expanded, and the code will be parsed and annotated
in the expanded state. In a second step, the formatting decisions
in the annotated expanded code will be reconstructed onto the
original unexpanded macro call.
Eventually, this will allow to remove special-case code for
various macro options we accumulated over the years in favor of
one principled mechanism.
Differential Revision: https://reviews.llvm.org/D144170
The token annotator doesn't annotate the template opener and closer
as such if they enclose an overloaded operator. This causes the
space between the operator and the closer to be removed, resulting
in invalid C++ code.
Fixes#58602.
Differential Revision: https://reviews.llvm.org/D143755
Token annotator incorrectly annotates operator& as a reference type in
situations like Boost serialization archives:
https://www.boost.org/doc/libs/1_81_0/libs/serialization/doc/tutorial.html
Add annotation rules for standalone and chained operator& instances while
preserving behavior for reference declarations at class scope. Add tests to
validate annotation and formatting behavior.
Differential Revision: https://reviews.llvm.org/D141959
There should not be any cases where the angle brackets of template
parameters are directly followed by a literal. It is more likely that a
comparison is taking place instead.
This patch makes the TokenAnnotator prefer to annotate < and > as
operators when directly followed by a literal. A similar check already
exists for literals directly *before* potential template args.
Fixes https://github.com/llvm/llvm-project/issues/60140
Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D142139
This reverts commit 879bfe6a979295f834b76df66b19a203b93eed0f.
owenpan@ pointed out on https://reviews.llvm.org/D140956 that this
actually makes the formatting more consistent, so it's not a regression.
This patch properly recognizes the generic selection expression
introduced in C11, by adding an additional token type for the colons
present in such expressions.
Previously, they would be recognized as
"inline ASM colons" purely by the fact that those are the last thing
checked for.
I tried to avoid adding an addition token type, but since colons by
default like having spaces around them, I chose to add a new type so
that no space is added after the type selector.
Currently, no aspect of the formatting of these expressions in able to
be configured, as I'm not sure what could even be configured here.
One notable thing is that association list is always formatted as
either entirely on one line, if it can fit, or with line breaks
after every comma in the expression (also after the controlling expr.)
This visually makes them more similar to switch statements when long,
matching the behaviour of the selection expression, being that of a sort
of switch on types, but also allows for terseness when only selecting
for a few things.
Fixes https://github.com/llvm/llvm-project/issues/18080
Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D139211
D119599 added the ability to align compound assignments, right aligning
them in order to line up at the equals sign.
However, that patch didn't account for AlignTokens being called
recursively across scopes, which reset the right justification to be
false in any scope besides the top scope. This meant the compound
assignments were aligned, just not at the right place.
(No tests also ever introduced any scopes)
This patch makes sure to inherit the right justification value, just as
every other parameter is passed on.
Fixes https://github.com/llvm/llvm-project/issues/58029
Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D141288
This reverts commit a28f0747c2f3728bd8a6f64f7c8ba80b4e0cda9f.
It appears that this regresses some function definitions, added an
example as a comment over at https://reviews.llvm.org/D140956.
If a function with a `requires` clause as a constraint has a decltype
return type, such as `decltype(auto)`, the decltype was seen to be part
of the constraint clause, rather than as part of the function
declaration, causing it to be placed on the wrong line.
This patch disallows decltype to be a part of these clauses
Fixes https://github.com/llvm/llvm-project/issues/59578
Depends on D140339
Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D140312
Previously, clang-format relied on a special method to parse concept
definitions, `UnwrappedLineParser::parseConcept()`, which deferred to
`UnwrappedLineParser::parseConstraintExpression()`. This is problematic,
because the C++ grammar treats concepts and requires clauses
differently, causing issues such as https://github.com/llvm/llvm-project/issues/55898 and https://github.com/llvm/llvm-project/issues/58130.
This patch removes `parseConcept`, letting the formatter parse concept
definitions as more like what they actually are, fancy bool definitions.
NOTE that because of this, some long concept definitions change in their
formatting, as can be seen in the changed tests. This is because of a
change in split penalties, caused by a change in MightBeFunctionDecl on
the concept definition line, which was previously `true` but with this
patch is now `false`.
One might argue that `false` is a more "correct" value for concept
definitions, but I'd be fine with setting it to `true` again to maintain
compatibility with previous versions.
Fixes https://github.com/llvm/llvm-project/issues/58130
Depends on D140330
Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D140339
This brings the noexcept qualifier more visually in line with the other
keyword qualifiers, such as "final" and "override".
Originally reported as https://github.com/llvm/llvm-project/issues/44542,
it was closed as "working by design" and reinforcing tests were added
as part of a218706cba90248be0c60bd6a8f10dbcf0270955. The exact spacing
depended on the `PointerAlignment` option, where the default value of
`Right` would leave no space.
This patch seeks to change this behaviour, regardless of the configured
`PointerAlignment` option (matching the previous behaviour of the `Left`
option).
Closes https://github.com/llvm/llvm-project/issues/59729
Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D140767
The C++ standard doesn't require that class template deduction guides
be templates themselves, but previously `isDeductionGuide` would assert
for the existence of a template closer or requires clause closer before
the deduction guide declaration.
This patch simply removes that check. Because of this, a test which
asserted that `x()->x<1>;` *isn't* a deduction guide failed, as it is
now formatted as a deduction guide. However, as @JohelEGP demonstrated,
it is [possible to make that a viable deduction guide][1].
Thus, that test has been removed, but other tests related to
non-template class template deduction guides have been added.
Fixes https://github.com/llvm/llvm-project/issues/55142
[1]: https://compiler-explorer.com/z/Wx3K6d5K9
Reviewed By: HazardyKnusperkeks, owenpan
Differential Revision: https://reviews.llvm.org/D139416
This assertion failure was introduced in 9ed2e68c9ae5 and is
manifested when both RemoveBracesLLVM and MacroBlockBegin are set.
Fixes#59335.
Differential Revision: https://reviews.llvm.org/D139281
The BracketAlignmentStyle BAS_BlockIndent was forcing breaks before a
closing right parenthesis yielding strange-looking results in case of
code structures that have a left parens immediately following a right
parens ")(" such as is seen with indirect function calls via function
pointers and with type casting.
Fixes 57250.
Fixes 58496.
Differential Revision: https://reviews.llvm.org/D137762
I'm not exactly sure what the intent of that section of
`spaceRequiredBetween` is doing, it seems to handle templates and <<,
but the part which adds spaces before parens is way later, as part
of `spaceRequiredBeforeParens`.
Fixes https://github.com/llvm/llvm-project/issues/58821
Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D137474
I want to reduce the size of ForatTest.cpp with its still wopping 25k
lines it is a burden on the compiler and editor (mine is clangd
powered).
This are tests which are really serving a different purpose than
formatting.
I've copied the code and made the following changes:
- Dropped the ; at the end of some macros, all macro "invocations"
already have their own ;.
- Dropped the _F, we don't need a fxiture here.
Differential Revisison: https://reviews.llvm.org/D137823
Ran into an issue where function declarations inside function
scopes or uses of sizeof inside a function would treat the && in
'sizeof(Type &&)' as a binary operator.
Attempt to fix this by assuming reference when followed by ',' or
')'. Also adds tests for these.
Also hit an edge case in another test that treated "and" the same
as "&&" since it parses as C++. Changed the "and" to "also" so it
is no longer a keyword.
Fixes#58923.
Differential Revision: https://reviews.llvm.org/D137755
