Summary:
Align sequential generic type constraints on a type.
Indent sequential generic type constraints on different types as continuations.
Do not allow '(' and '<' within a generic type constraint to open new scopes.
Reviewers: krasimir
Subscribers: cfe-commits, MyDeveloperDay
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D76597
Summary:
Treat each C# generic type constraint, `where T: ...`, as a line.
Add C# keyword: where
Add Token Types: CSharpGenericTypeConstraint, CSharpGenericTypeConstraintColon, CSharpGenericTypeConstraintComma.
This patch does not wrap generic type constraints well, that will be addressed in a follow up patch.
Reviewers: krasimir
Reviewed By: krasimir
Subscribers: cfe-commits, MyDeveloperDay
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D76367
Summary:
Disable merging of Type? into a single token.
Merge ?? ?. and ?[ into a single token.
Reviewers: krasimir, MyDeveloperDay
Reviewed By: krasimir
Subscribers: cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D75368
Summary:
Do not confuse C# nullable types with conditional expressions.
Do not put a space before the `?` in `[access-modifier] Type? variableName;`
Reviewers: krasimir, MyDeveloperDay
Reviewed By: krasimir, MyDeveloperDay
Subscribers: cfe-commits, MyDeveloperDay
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D75261
Summary:
No longer merge 'name' and ':' into a single token.
Ensure that line breaks cannot be placed before or after a named-argument colon.
Ensure that no space is inserted before a named-argument colon.
Reviewers: krasimir
Reviewed By: krasimir
Subscribers: cfe-commits, MyDeveloperDay
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D75244
Summary:
Ensure that there are spaces around braces '{', '}'.
Ensure that there is a space before and after '=>'.
Ensure that 'async' and 'when' are considered as keywords when inserting spaces.
Reviewers: krasimir, MyDeveloperDay
Reviewed By: krasimir
Tags: #clang-format
Differential Revision: https://reviews.llvm.org/D75129
This option add a line break then a lambda is inside a function call.
Reviewers : djasper, klimek, krasimir, MyDeveloperDay
Reviewed By: MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D44609
Summary:
C# attributes can appear on classes and methods, in which case they should go on their own line, or on method parameters in which case
they should be left inline.
Reviewers: krasimir, MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: klimek
Tags: #clang-format
Differential Revision: https://reviews.llvm.org/D74265
Summary: Add comments to the list of tokens that can follow the ']' at the end of a C# attribute specifier to prevent comments after attribute specifiers from being formatted as continuations.
Reviewers: MyDeveloperDay, krasimir
Reviewed By: MyDeveloperDay
Tags: #clang-format
Differential Revision: https://reviews.llvm.org/D73977
Summary:
clang-format currently always wraps the body of non-empty arrow
functions:
const x = () => {
z();
};
This change implements support for the `AllowShortLambdasOnASingleLine`
style options, controlling the indent style for arrow function bodies
that have one or fewer statements. SLS_All puts all on a single line,
SLS_Inline only arrow functions used in an inline position.
const x = () => { z(); };
Multi-statement arrow functions continue to be wrapped. Function
expressions (`a = function() {}`) and function/method declarations are
unaffected as well.
Reviewers: krasimir
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D73335
Summary:
An heuristic targetting `x && x->foo` was targed overly broadly and caused the
last T&& to be treated as a binary operator.
Reviewers: hokein
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D73334
Contributed by jbcoe!
Summary: Unless SpaceBeforeParensOptions is set to SBPO_Never, a space will be put between `using` and `(` in C# code.
Reviewers: klimek, MyDeveloperDay, krasimir
Reviewed By: krasimir
Subscribers: MyDeveloperDay, cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D72144
Summary: This diff expands the SpacesAroundConditions option added in D68346 to include adding spaces to catch statements.
Reviewed By: MyDeveloperDay
Patch by: timwoj
Differential Revision: https://reviews.llvm.org/D72793
Summary:
Revision a75f8d98d7 fixed spacing for operators,
but caused the const and non-const versions to diverge:
```
// With Style.PointerAlignment = FormatStyle::PAS_Left:
struct A {
operator char*() { return ""; }
operator const char *() const { return ""; }
};
```
The code was checking if the type specifier was directly preceded by `operator`.
However there could be comments and `const/volatile` in between.
Reviewers: mprobst
Reviewed By: mprobst
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D72911
Summary:
As a followup to D69144, this diff fixes the coroutine keyword spacing
for co_yield / co_returning negative numbers.
Reviewers: modocache, sammccall, Quuxplusone
Reviewed By: modocache
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D69180
Patch by Jonathan Thomas (jonathoma)!
Summary: Adds a new option SpaceBeforeBrackets to add spaces before brackets (i.e. int a[23]; -> int a [23];) This is present as an option in the Visual Studio C++ code formatting settings, but there was no matching setting in clang-format.
Reviewers: djasper, MyDeveloperDay, mitchell-stellar
Reviewed By: MyDeveloperDay
Subscribers: llvm-commits, cfe-commits, klimek
Patch by: Anteru
Tags: #clang, #clang-format, #llvm
Differential Revision: https://reviews.llvm.org/D6920
Summary:
This fixes an edge case in the `SpacesInSquareBrackets` option where an initial `&ref` lambda parameter is not padded with an initial space.
`int foo = [&bar ]() {}` is fixed to give `int foo = [ &bar ]() {}`
Reviewers: MyDeveloperDay, klimek, sammccall
Reviewed by: MyDeveloperDay
Subscribers: cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D69649
Summary:
The code `throw -1;` is currently formatted by clang-format as
`throw - 1;`. This diff adds a fix for this edge case and a test to check
for this in the future.
For context, I am looking into a related bug in the clang-formatting of
coroutine keywords: `co_yield -1;` is also reformatted in this manner
as `co_yield - 1;`. A later diff will add these changes and tests for the
`co_yield` and `co_return` keywords.
Patch by Jonathan Thomas (jonathoma)!
Reviewers: modocache, sammccall, Quuxplusone
Reviewed By: sammccall
Subscribers: cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D69144
llvm-svn: 375258
Summary:
r373922 added checks for a few tokens that, following an `)` make it
unlikely that the `)` is the closing paren of a cast expression. The
specific check for `tok::l_square` there introduced a regression for
casts of Obj-C calls, like:
```
(cast)[func arg]
```
From the tests added in r373922, I believe the `tok::l_square` case is added to
capture the case where a non-cast `)` is directly followed by an
attribute specifier, like:
```
int f(int x) [[noreturn]];
```
I've specialized the code to look for such attribute specifier instead
of `tok::l_square` in general. Also, I added a regression test and moved
the test cases added in r373922 to an already existing place documenting
other instances of historically misidentified casts.
Reviewers: MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D69164
llvm-svn: 375247
Summary:
r373165 fixed an issue where a templated noexcept member function with a
reference qualifier would be indented more than expected:
```
// Formatting produced with LLVM style with AlwaysBreakTemplateDeclarations: Yes
// before r373165:
struct f {
template <class T>
void bar() && noexcept {}
};
// after:
struct f {
template <class T>
void bar() && noexcept {}
};
```
The way this is done is that in the AnnotatingParser in
`lib/FormatTokenAnnotator.cpp` the determination of the usage of a `&` or `&&`
(the line in determineTokenType
```
Current.Type = determineStarAmpUsage(...
```
is not performed in some cases anymore, combining with a few additional related
checks afterwards. The net effect of these checks results in the `&` or `&&`
token to start being classified as `TT_Unknown` in cases where before `r373165`
it would be classified as `TT_UnaryOperator` or `TT_PointerOrReference` by
`determineStarAmpUsage`.
This inadvertently caused 2 classes of regressions I'm aware of:
- The address-of `&` after a function assignment would be classified as
`TT_Unknown`, causing spaces to surround it, disregarding style options:
```
// before r373165:
void (*fun_ptr)(void) = &fun;
// after:
void (*fun_ptr)(void) = & fun;
```
- In cases where there is a function declaration list -- looking macro between
a template line and the start of the function declaration, an `&` as part of
the return type would be classified as `TT_Unknown`, causing spaces to
surround it:
```
// before r373165:
template <class T>
DEPRECATED("lala")
Type& foo();
// after:
template <class T>
DEPRECATED("lala")
Type & foo();
```
In these cases the problems are rooted in the skipping of the classification of
a `&` (and similarly `&&`) by determineStarAmpUsage which effects the formatting
decisions later in the pipeline.
I've looked into the goal of r373165 and noticed that replacing `noexcept` with
`const` in the given example produces no extra indentation with the old code:
```
// before r373165:
struct f {
template <class T>
int foo() & const {}
};
struct f {
template <class T>
int foo() & noexcept {}
};
```
I investigated how clang-format annotated these two examples differently to
determine the places where the processing of both diverges in the pipeline.
There were two places where the processing diverges, causing the extra indent in
the `noexcept` case:
1. The `const` is annotated as a `TT_TrailingAnnotation`, whereas `noexcept`
is annotated as `TT_Unknown`. I've updated the `determineTokenType` function
to account for this by adding a missing `tok:kw_noexcept` to the clause that
marks a token as `TT_TrailingAnnotation`.
2. The `&` in the second example is wrongly identified as `TT_BinaryOperator`
in `determineStarAmpUsage`. This is the reason for the extra indentation --
clang-format gets confused and thinks this is an expression.
I've updated `determineStarAmpUsage` to check for `tok:kw_noexcept`.
With these two updates in place, the additional parsing introduced by r373165
becomes unnecessary and all added tests pass (with updates, as now clang-format
respects the style configuration for spaces around the `&` in the test
examples).
I've removed these additions and added regression tests for the cases above.
Reviewers: AndWass, MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D68695
llvm-svn: 374172
Summary:
clang-format is incorrectly thinking the parameter parens are part of a cast operation, this is resulting in there sometimes being not space between the paren and the noexcept (and other keywords like volatile etc..)
```
void operator++(int) noexcept;
void operator++(int &) noexcept;
void operator delete(void *, std::size_t, const std::nothrow_t &)noexcept;
```
Reviewers: klimek, owenpan, mitchell-stellar
Reviewed By: mitchell-stellar
Subscribers: cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D68481
llvm-svn: 373922
Summary:
This patch makes the `SpacesInSquareBrackets` setting also apply to C++ lambdas with parameters.
Looking through the revision history, it appears support for only array brackets was added, and lambda brackets were ignored. Therefore, I am inclined to think it was simply an omission, rather than a deliberate choice.
See https://bugs.llvm.org/show_bug.cgi?id=17887 and https://reviews.llvm.org/D4944.
Reviewers: MyDeveloperDay, reuk, owenpan
Reviewed By: MyDeveloperDay
Subscribers: cfe-commits
Patch by: mitchell-stellar
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D68473
llvm-svn: 373821
Summary:
According to the clang-format documentation, "Fundamentally, C++11 braced lists are formatted exactly like function calls would be formatted in their place. If the braced list follows a name (e.g. a type or variable name), clang-format formats as if the `{}` were the parentheses of a function call with that name."
This patch furthers the treatment of C++11 braced list braces as parentheses by respecting the `SpacesInParentheses` setting.
Reviewers: MyDeveloperDay, reuk, owenpan
Reviewed By: MyDeveloperDay
Subscribers: cfe-commits
Tags: #clang-format, #clang
Patch By: mitchell-stellar
Differential Revision: https://reviews.llvm.org/D68415
llvm-svn: 373751
Summary:
https://bugs.llvm.org/show_bug.cgi?id=43531
Fix for clang-format incorrectly handles "alternative operators" as described by https://en.cppreference.com/w/cpp/language/operator_alternative
compl = ~
not = !
these are unary operators, and clang-format will remove the space between them and a numeric constant
this incorrectly formats the following code
```
int a compl 5;
int a not 5;
```
into:
```
int a compl5;
int a not5;
```
The code adds FIXME unit tests for "alternative token" representations for {} [] and # as defined by the same link, which would require a more detailed change to the FormatTokenLexer
Reviewers: klimek, reuk, owenpan, mitchell-stellar, STL_MSFT
Reviewed By: mitchell-stellar
Subscribers: cfe-commits
Tags: #clang-format, #clang-tools-extra, #clang
Differential Revision: https://reviews.llvm.org/D68332
llvm-svn: 373750
Summary:
https://bugs.llvm.org/show_bug.cgi?id=42417
This revision removes the extra space between the opertor-> and the parens ()
```
class Bug {
auto operator-> () -> int*;
auto operator++(int) -> int;
};
```
Reviewers: klimek, owenpan, byoungyoung, mitchell-stellar
Reviewed By: mitchell-stellar
Subscribers: cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D68242
llvm-svn: 373746
Summary:
When formatting C# there can be issues with a lack of spaces between `using (` , `foreach (` and generic types
The C# code
```
public class Foo
{
Dictionary<string,string> foo;
}
```
will be formatted as
```
public class Foo
{
Dictionary<string, string>foo;
^^^^^ missing a space
}
```
This revision also reverts some of {D66662} in order to make this cleaner and resolve an issues seen by @owenpan that the formatting didn't add a space when not in a code block
This also transforms C# foreach commands to be seen as tok::kw_for commands (to ensure foreach gets the same Brace Wrapping behavior as for without littering the code with `if(Style.isCSharp())`
Reviewers: owenpan, klimek, russellmcc, mitchell-stellar
Reviewed By: mitchell-stellar
Subscribers: cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D67660
llvm-svn: 373709
Summary:
This is a fix for https://bugs.llvm.org/show_bug.cgi?id=43333
This comes with 3 main parts
- C# attributes cause function names on a new line even when AlwaysBreakAfterReturnType is set to None
- Add AlwaysBreakAfterReturnType to None by default in the Microsoft style,
- C# unit tests are not using Microsoft style (which we created to define the default C# style to match a vanilla C# project).
Reviewers: owenpan, klimek, russellmcc, mitchell-stellar
Reviewed By: mitchell-stellar
Subscribers: cfe-commits
Tags: #clang-tools-extra, #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D67629
llvm-svn: 373707
Jonathan Coe