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 a218706cba. 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
Previously, the parens of a requires expression's "parameters" were not
explicitly set, meaning they ended up as whatever the outer scope was.
This is a problem in some cases though, since the process of determining
star/amp checks if the token is inside of an expression context
This patch always makes sure the context between those parens are always
set to not be an expression
Fixes https://github.com/llvm/llvm-project/issues/59600
Reviewed By: HazardyKnusperkeks, owenpan
Differential Revision: https://reviews.llvm.org/D140330
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
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
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
If true, colons in ASM parameters will be placed after line breaks.
true:
asm volatile("string",
:
: val);
false:
asm volatile("string", : : val);
Differential Revision: https://reviews.llvm.org/D91950
This revision fixes typos where there are 2 consecutive words which are
duplicated. There should be no code changes in this revision (only
changes to comments and docs). Do let me know if there are any
undesirable changes in this revision. Thanks.
Before this patch code like this:
```
if (Class* obj{getObject()}) { }
```
would be mis-formated since the * would be annotated as a
binaryoperator.
This patch changes the * to become a PointerOrReference instead
and fixes the formatting issues.
Reviewed By: HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D137327
They were annotated with TrailingAnnotation, which they are not. And
that resulted in some quirky formatting in some cases.
Differential Revision: https://reviews.llvm.org/D136635
In our code-base we auto-generate pragma regions the regions
look like method signatures like:
`#pragma region MYREGION(Foo: bar)`
The problem here was that the rest of the line after region
was not marked as stringliteral as in the case of pragma mark
so clang-format tried to change the formatting based on the
method signature.
Added test and mark it similar as pragma mark.
Reviewed By: owenpan
Differential Revision: https://reviews.llvm.org/D136336
... of TokenAnnotator::splitPenalty. That is in my eyes a bit clearer
in the workflow.
As a drive-by introduce (but not adapt anywhere else) isProto().
Differential Revision: https://reviews.llvm.org/D135871
There is no reason why unions should be handled differently, I think
they are just forgotten since they are not used that often.
No test case added, since that would be complicated to produce.
Differential Revision: https://reviews.llvm.org/D135872
Currently, we parse lines inside of a compiler `#pragma` the same way we
parse any other line. This is fine for some cases, like separating
expressions and adding proper spacing, but in others it causes some poor
results from miscategorizing some tokens.
For example, the OpenMP offloading uses certain clauses that contain
special characters like `map(tofrom : A[0:N])`. This will be formatted
poorly as it will be split between lines on the first colon.
Additionally the subscript notation will lead to poor spacing. This can
be seen in the OpenMP tests as the automatic clang formatting with
inevitably ruin the formatting.
For example, the following contrived example will be formatted poorly.
```
#pragma omp target teams distribute collapse(2) map(to: A[0 : M * K]) \
map(to: B[0:K * N]) map(tofrom:C[0:M*N]) firstprivate(Alpha) \
firstprivate(Beta) firstprivate(X) firstprivate(D) firstprivate(Y) \
firstprivate(E) firstprivate(Z) firstprivate(F)
```
This results in this when formatted, which is far from ideal.
```
#pragma omp target teams distribute collapse(2) map(to \
: A [0:M * K]) \
map(to \
: B [0:K * N]) map(tofrom \
: C [0:M * N]) firstprivate(Alpha) \
firstprivate(Beta) firstprivate(X) firstprivate(D) firstprivate(Y) \
firstprivate(E) firstprivate(Z) firstprivate(F)
```
This patch seeks to improve this by adding extra logic where the parsing goes
awry. This is primarily caused by the colon being parsed as an inline-asm
directive and the brackes an objective-C expressions. Also the line gets
indented every single time the line is dropped.
This doesn't implement true parsing handling for OpenMP statements.
Reviewed By: HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D136100
Inside the arguments part of a function pointer declaration,
`determineStarAmpUsage` results in a binary operator rather than
pointers, because said parens are assumed to be an expression.
This patch correctly marks the argument parens of a function
pointer type as not an expression. Note that this fix already
existed for Objective-C blocks as part of f1f267b447.
As Objective-C blocks and C/C++ function pointers share a lot
of the same logic, that fix also makes sense here.
Fixes https://github.com/llvm/llvm-project/issues/31659
Differential Revision: https://reviews.llvm.org/D135707
Working in a mixed environment of both vscode/vim with a team configured prettier configuration, this can leave clang-format and prettier fighting each other over the formatting of arrays, both simple arrays of elements.
This review aims to add some "control knobs" to the Json formatting in clang-format to help align the two tools so they can be used interchangeably.
This will allow simply arrays `[1, 2, 3]` to remain on a single line but will break those arrays based on context within that array.
Happy to change the name of the option (this is the third name I tried)
Reviewed By: HazardyKnusperkeks, owenpan
Differential Revision: https://reviews.llvm.org/D133589
There already exists logic to disallow requires *expressions* to be
treated as function declarations, but this expands it to include
requires *clauses*, when they happen to also be parenthesized.
Previously, in the following case:
```
template <typename T>
requires(Foo<T>)
T foo();
```
The line with the requires clause was actually being considered as the
line with the function declaration due to the parentheses, and the
*real* function declaration on the next line became a trailing
annotation
(Together with https://reviews.llvm.org/D134049) Fixes https://github.com/llvm/llvm-project/issues/56213
Reviewed By: HazardyKnusperkeks, owenpan
Differential Revision: https://reviews.llvm.org/D134052
In the following construction:
`template <typename T> requires Foo<T> || Bar<T> auto func() -> int;`
The `->` of the trailing return type was actually considered as an
operator as part of the binary operation in the requires clause, with
the precedence level of `PrecedenceArrowAndPeriod`, leading to fake
parens being inserted in strange locations, that would never be closed.
Fixes one part of https://github.com/llvm/llvm-project/issues/56213
(the rest will probably be in a separate patch)
Reviewed By: HazardyKnusperkeks, owenpan
Differential Revision: https://reviews.llvm.org/D134049
Fixes https://github.com/llvm/llvm-project/issues/57738
old
```
#define FOO(typeName, realClass) \
{ \
#typeName, foo < FooType>(new foo <realClass>(#typeName)) \
}
```
new
```
#define FOO(typeName, realClass) \
{ #typeName, foo<FooType>(new foo<realClass>(#typeName)) }
```
Previously, when an UnwrappedLine began with a hash in a macro
definition, the program incorrectly assumed the line was a preprocessor
directive. It should be stringification.
The rule in spaceRequiredBefore was added in 8b5297117b. Its purpose is
to add a space in an include directive. It also added a space to a
template opener when the line began with a stringification hash. So we
changed it.
Reviewed By: HazardyKnusperkeks, owenpan
Differential Revision: https://reviews.llvm.org/D133954
With the AlwaysBreakTemplateDeclarations option, having a constructor
template for a type consisting of all-uppercase letters with a
noexcept specifier would put said noexcept specifier on its own blank
line.
This is because the all-uppercase type is understood as a macro-like
attribute (such as DEPRECATED()), and noexcept is seen as the
declaration. However, noexcept is a keyword and cannot be an
identifier on its own.
Fixes https://github.com/llvm/llvm-project/issues/56216
Differential Revision: https://reviews.llvm.org/D132189
Adds
* `__add_lvalue_reference`
* `__add_pointer`
* `__add_rvalue_reference`
* `__decay`
* `__make_signed`
* `__make_unsigned`
* `__remove_all_extents`
* `__remove_extent`
* `__remove_const`
* `__remove_volatile`
* `__remove_cv`
* `__remove_pointer`
* `__remove_reference`
* `__remove_cvref`
These are all compiler built-in equivalents of the unary type traits
found in [[meta.trans]][1]. The compiler already has all of the
information it needs to answer these transformations, so we can skip
needing to make partial specialisations in standard library
implementations (we already do this for a lot of the query traits). This
will hopefully improve compile times, as we won't need use as much
memory in such a base part of the standard library.
[1]: http://wg21.link/meta.trans
Co-authored-by: zoecarver
Reviewed By: aaron.ballman, rsmith
Differential Revision: https://reviews.llvm.org/D116203
- Modify TokenAnnotator to work fine with java-style array declarations.
- Add test for aligning of java declarations.
Fixes#55931.
Differential Revision: https://reviews.llvm.org/D129628
Adds
* `__add_lvalue_reference`
* `__add_pointer`
* `__add_rvalue_reference`
* `__decay`
* `__make_signed`
* `__make_unsigned`
* `__remove_all_extents`
* `__remove_extent`
* `__remove_const`
* `__remove_volatile`
* `__remove_cv`
* `__remove_pointer`
* `__remove_reference`
* `__remove_cvref`
These are all compiler built-in equivalents of the unary type traits
found in [[meta.trans]][1]. The compiler already has all of the
information it needs to answer these transformations, so we can skip
needing to make partial specialisations in standard library
implementations (we already do this for a lot of the query traits). This
will hopefully improve compile times, as we won't need use as much
memory in such a base part of the standard library.
[1]: http://wg21.link/meta.trans
Co-authored-by: zoecarver
Reviewed By: aaron.ballman, rsmith
Differential Revision: https://reviews.llvm.org/D116203
These statements are like switch statements in C, but without the 'case'
keyword in labels.
How labels are parsed. In UnwrappedLineParser, the program tries to
parse a statement every time it sees a colon. In TokenAnnotator, a
colon that isn't part of an expression is annotated as a label.
The token type `TT_GotoLabelColon` is added. We did not include Verilog
in the name because we thought we would eventually have to fix the
problem that case labels in C can't contain ternary conditional
expressions and we would use that token type.
The style is like below. Labels are on separate lines and indented by
default. The linked style guide also has examples where labels and the
corresponding statements are on the same lines. They are not supported
for now.
https://github.com/lowRISC/style-guides/blob/master/VerilogCodingStyle.md
```
case (state_q)
StIdle:
state_d = StA;
StA: begin
state_d = StB;
end
endcase
```
Differential Revision: https://reviews.llvm.org/D128714
Now things inside hierarchies like modules and interfaces are
indented. When the module header spans multiple lines, all except the
first line are indented as continuations. We added the property
`IsContinuation` to mark lines that should be indented this way.
In order that the colons inside square brackets don't get labeled as
`TT_ObjCMethodExpr`, we added a check to only use this type when the
language is not Verilog.
Differential Revision: https://reviews.llvm.org/D128712
Now stuff inside begin-end blocks get indented.
Some tests are moved into FormatTestVerilog.Block from
FormatTestVerilog.If because they have nothing to do with if statements.
Reviewed By: HazardyKnusperkeks, owenpan
Differential Revision: https://reviews.llvm.org/D128711
