Summary:
The previous change in https://reviews.llvm.org/D77311 attempted to
detect more C++ keywords. However it also precisely detected all
JavaScript keywords. That's generally correct, but many JavaScripy
keywords, e.g. `get`, are so-called pseudo-keywords. They can be used in
positions where a keyword would never be legal, e.g. in a dotted
expression:
x.type; // type is a pseudo-keyword, but can be used here.
x.get; // same for get etc.
This change introduces an additional parameter to
`IsJavaScriptIdentifier`, allowing clients to toggle whether they want
to allow `IdentifierName` tokens, i.e. pseudo-keywords.
Reviewers: krasimir
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D77548
Summary:
C++ defines a number of keywords that are regular identifiers in
JavaScript, e.g. `concept`:
const concept = 1; // legit JS
This change expands the existing `IsJavaScriptIdentifier(Tok)` function
to return false for C++ keywords that aren't keywords in JS.
Reviewers: krasimir
Subscribers: jfb, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D77311
Commit "[clang-format] Handle C# generic type constraints",
dcbcec4822
regressed the formatting of code containing `where` as an identifier in other
languages.
This fixes a regression from D69573 which broke the following example:
$ echo 'operator C<T>*();' | bin/clang-format --style=Chromium
operator C<T> *();
(There should be no space before the asterisk.)
It seems the problem is in TokenAnnotator::spaceRequiredBetween(),
which only looked at the token to the left of the * to see if it was a
type or not. That code only handled simple types or identifiers, not
templates or qualified types. This patch addresses that.
Differential revision: https://reviews.llvm.org/D76850
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
Jonathan Coe