[clang-format] Optionally insert a space after unary ! operator

llvm-svn: 357908

[clang-format] Fix bug https://bugs.llvm.org/show_bug.cgi?id=41413

Differential Revision: https://reviews.llvm.org/D60374

llvm-svn: 357877

[clang-format] Fix Bug 41407
Differential Revision: https://reviews.llvm.org/D60359

llvm-svn: 357851

[clang-format] BreakAfterReturnType ignored on functions with numeric template parameters

Summary:
Addresses PR40696 - https://bugs.llvm.org/show_bug.cgi?id=40696

The BreakAfterReturnType didn't wo

[clang-format] BreakAfterReturnType ignored on functions with numeric template parameters

Summary:
Addresses PR40696 - https://bugs.llvm.org/show_bug.cgi?id=40696

The BreakAfterReturnType didn't work if it had a single arguments which was a template with an integer template parameter

```
int foo(A<8> a) { return a; }
```

When run with the Mozilla style. would not break after the `int`

```
int TestFn(A<8> a)
{
return a;
}

```

This revision resolves this issue by allowing numeric constants to be considered function parameters if if seen inside `<>`

Reviewers: djasper, klimek, JonasToth, krasimir, reuk, alexfh

Reviewed By: klimek

Subscribers: cfe-commits, llvm-commits

Tags: #clang-tools-extra

Differential Revision: https://reviews.llvm.org/D59309

llvm-svn: 357837

show more ...

[clang-format]: Add NonEmptyParentheses spacing option

This patch aims to add support for the following rules from the JUCE coding standards:

- Always put a space before an open parenthesis that co

[clang-format]: Add NonEmptyParentheses spacing option

This patch aims to add support for the following rules from the JUCE coding standards:

- Always put a space before an open parenthesis that contains text - e.g. foo (123);
- Never put a space before an empty pair of open/close parenthesis - e.g. foo();

Patch by Reuben Thomas

Differential Revision: https://reviews.llvm.org/D55170

llvm-svn: 357344

show more ...

[clang-format] Add style option AllowShortLambdasOnASingleLine

Summary:
This option `AllowShortLambdasOnASingleLine` similar to the other `AllowShort*` options, but applied to C++ lambdas.

Reviewer

[clang-format] Add style option AllowShortLambdasOnASingleLine

Summary:
This option `AllowShortLambdasOnASingleLine` similar to the other `AllowShort*` options, but applied to C++ lambdas.

Reviewers: djasper, klimek

Reviewed By: klimek

Subscribers: MyDeveloperDay, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D57687

llvm-svn: 357027

show more ...

Clang-format: add finer-grained options for putting all arguments on one line

Summary:
Add two new options,
AllowAllArgumentsOnNextLine and
AllowAllConstructorInitializersOnNextLine. These mirror t

Clang-format: add finer-grained options for putting all arguments on one line

Summary:
Add two new options,
AllowAllArgumentsOnNextLine and
AllowAllConstructorInitializersOnNextLine. These mirror the existing
AllowAllParametersOfDeclarationOnNextLine and allow me to support an
internal style guide where I work. I think this would be generally
useful, some have asked for it on stackoverflow:

https://stackoverflow.com/questions/30057534/clang-format-binpackarguments-not-working-as-expected

https://stackoverflow.com/questions/38635106/clang-format-how-to-prevent-all-function-arguments-on-next-line

Reviewers: djasper, krasimir, MyDeveloperDay

Reviewed By: MyDeveloperDay

Subscribers: jkorous, MyDeveloperDay, aol-nnov, lebedev.ri, uohcsemaj, cfe-commits, klimek

Differential Revision: https://reviews.llvm.org/D40988

Patch By: russellmcc (Russell McClellan)

llvm-svn: 356834

show more ...

[clang-format] BeforeHash added to IndentPPDirectives

Summary:
The option BeforeHash added to IndentPPDirectives.
Fixes Bug 36019. https://bugs.llvm.org/show_bug.cgi?id=36019

Reviewers: djasper, kl

[clang-format] BeforeHash added to IndentPPDirectives

Summary:
The option BeforeHash added to IndentPPDirectives.
Fixes Bug 36019. https://bugs.llvm.org/show_bug.cgi?id=36019

Reviewers: djasper, klimek, krasimir, sammccall, mprobst, Nicola, MyDeveloperDay

Reviewed By: klimek, MyDeveloperDay

Subscribers: kadircet, MyDeveloperDay, mnussbaum, geleji, ufna, cfe-commits

Patch by to-mix.

Differential Revision: https://reviews.llvm.org/D52150

llvm-svn: 356613

show more ...

[clang-format] structured binding in range for detected as Objective C

Summary:
Sometime after 6.0.0 and the current trunk 9.0.0 the following code would be considered as objective C and not C++

Re

[clang-format] structured binding in range for detected as Objective C

Summary:
Sometime after 6.0.0 and the current trunk 9.0.0 the following code would be considered as objective C and not C++

Reported by: https://twitter.com/mattgodbolt/status/1096188576503644160

$ clang-format.exe test.h
Configuration file(s) do(es) not support Objective-C: C:\clang\build\.clang-format

--- test.h --
```

std::vector<std::pair<std::string,std::string>> C;

void foo()
{
for (auto && [A,B] : C)
{
std::string D = A + B;
}
}
```
The following code fixes this issue of incorrect detection

Reviewers: djasper, klimek, JonasToth, reuk

Reviewed By: klimek

Subscribers: cfe-commits

Tags: #clang-tools-extra

Differential Revision: https://reviews.llvm.org/D59546

llvm-svn: 356575

show more ...

[clang-format] Propagate inferred language to getLLVMStyle() in getPredefinedStyle()

rC355158 added an optional language parameter to getLLVMStyle(), but this parameter was not used in getPredefined

[clang-format] Propagate inferred language to getLLVMStyle() in getPredefinedStyle()

rC355158 added an optional language parameter to getLLVMStyle(), but this parameter was not used in getPredefinedStyle(). Because unit tests directly specify the style, this codepath wasn't tested. Add an additional unit test for getStyle().

llvm-svn: 356099

show more ...

[clang-format] [PR25010] AllowShortIfStatementsOnASingleLine not working if an "else" statement is present

Summary:
Addressing: PR25010 - https://bugs.llvm.org/show_bug.cgi?id=25010

Code like:

```

[clang-format] [PR25010] AllowShortIfStatementsOnASingleLine not working if an "else" statement is present

Summary:
Addressing: PR25010 - https://bugs.llvm.org/show_bug.cgi?id=25010

Code like:

```
if(true) var++;
else {
var--;
}
```

is reformatted to be

```
if (true)
var++;
else {
var--;
}
```

Even when `AllowShortIfStatementsOnASingleLine` is true

The following revision comes from a +1'd suggestion in the PR to support AllowShortIfElseStatementsOnASingleLine

This suppresses the clause prevents the merging of the if when there is a compound else

Reviewers: klimek, djasper, JonasToth, alexfh, krasimir, reuk
Reviewed By: reuk
Subscribers: reuk, Higuoxing, jdoerfert, cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D59087

llvm-svn: 356031

show more ...

Revert "[clang-format] [PR25010] AllowShortIfStatementsOnASingleLine not working if an "else" statement is present"

This reverts commit b358cbb9b78389e20f7be36e1a98e26515c3ecce.

llvm-svn: 356030

[clang-format] [PR25010] AllowShortIfStatementsOnASingleLine not working if an "else" statement is present

Summary:
Addressing: PR25010 - https://bugs.llvm.org/show_bug.cgi?id=25010

Code like:

```

[clang-format] [PR25010] AllowShortIfStatementsOnASingleLine not working if an "else" statement is present

Summary:
Addressing: PR25010 - https://bugs.llvm.org/show_bug.cgi?id=25010

Code like:

```
if(true) var++;
else {
var--;
}
```

is reformatted to be

```
if (true)
var++;
else {
var--;
}
```

Even when `AllowShortIfStatementsOnASingleLine` is true

The following revision comes from a +1'd suggestion in the PR to support AllowShortIfElseStatementsOnASingleLine

This suppresses the clause prevents the merging of the if when there is a compound else

Reviewers: klimek, djasper, JonasToth, alexfh, krasimir, reuk
Reviewed By: reuk
Subscribers: reuk, Higuoxing, jdoerfert, cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D59087

llvm-svn: 356029

show more ...

[clang-format] broken after lambda with return type template with boolean literal

Summary:
A Lamdba with a return type template with a boolean literal (true,false) behaves differently to an integer

[clang-format] broken after lambda with return type template with boolean literal

Summary:
A Lamdba with a return type template with a boolean literal (true,false) behaves differently to an integer literal

https://bugs.llvm.org/show_bug.cgi?id=40910

Reviewers: klimek, djasper, JonasToth, alexfh, krasimir, jkorous

Reviewed By: jkorous

Subscribers: jkorous, cfe-commits

Tags: #clang-tools-extra

Differential Revision: https://reviews.llvm.org/D58922

llvm-svn: 355450

show more ...

[clang-format] Fix lambdas returning template specialization that contains operator in parameter

A template specialization of a template foo<int N> can contain integer constants and a whole bunch of

[clang-format] Fix lambdas returning template specialization that contains operator in parameter

A template specialization of a template foo<int N> can contain integer constants and a whole bunch of operators - e. g. foo< 1 ? !0 : (3+1)%4 >

Inspired by https://reviews.llvm.org/D58922

Differential Revision: https://reviews.llvm.org/D58934

llvm-svn: 355434

show more ...

[clang-format][NFC] Allow getLLVMStyle() to take a language

Summary:
getLLVMStyle() sets the default style, but doesn't take the language as a parameter, so can't set default parameters when they di

[clang-format][NFC] Allow getLLVMStyle() to take a language

Summary:
getLLVMStyle() sets the default style, but doesn't take the language as a parameter, so can't set default parameters when they differ from C++. This change adds LanguageKind as an input to getLLVMStyle so that we can start doing that.

See D55964 as a motivation for this, where we want Tablegen to be formatted differently than C++.

Reviewers: djasper, krasimir, MyDeveloperDay

Reviewed By: MyDeveloperDay

Subscribers: jdoerfert, MyDeveloperDay, kristina, cfe-commits, arphaman

Tags: #clang

Differential Revision: https://reviews.llvm.org/D56943

llvm-svn: 355123

show more ...

[clang-format] SpaceBeforeParens for lambda expressions

Add support for lambda expressions to the SpaceBeforeParens formatting
option.

Differential Revision: https://reviews.llvm.org/D58241

llvm-s

[clang-format] SpaceBeforeParens for lambda expressions

Add support for lambda expressions to the SpaceBeforeParens formatting
option.

Differential Revision: https://reviews.llvm.org/D58241

llvm-svn: 354880

show more ...

clang-format with UseTab: Always sometimes doesn't insert the right amount of tabs.

Trailing comments are not always aligned properly when UseTab is set to Always.

Consider:

int a; // x
int

clang-format with UseTab: Always sometimes doesn't insert the right amount of tabs.

Trailing comments are not always aligned properly when UseTab is set to Always.

Consider:

int a; // x
int bbbbbbbb; // x
With .clang-format:

---
Language: Cpp
BasedOnStyle: LLVM
UseTab: Always
...
The trailing comments of this code block should be aligned, but aren't

To align the first trailing comment it needs to insert 8 spaces. This should be
one tab plus six spaces. It skips the logic of the first partial tab in
FirstTabWidth (=2) + Style.TabWidth (=8) <= Spaces (=8) and only inserts one
tab. Proposed fix and test is attached.

Patch by Hylke Kleve.

Differential revision: https://reviews.llvm.org/D57655

llvm-svn: 354183

show more ...

[clang-format] Fix breaking of qualified operator

Summary:
From https://bugs.llvm.org/show_bug.cgi?id=40516
```
$ cat a.cpp
const NamespaceName::VeryLongClassName &NamespaceName::VeryLongClassName::

[clang-format] Fix breaking of qualified operator

Summary:
From https://bugs.llvm.org/show_bug.cgi?id=40516
```
$ cat a.cpp
const NamespaceName::VeryLongClassName &NamespaceName::VeryLongClassName::myFunction() {
// do stuff
}

const NamespaceName::VeryLongClassName &NamespaceName::VeryLongClassName::operator++() {
// do stuff
}
$ ~/ll/build/opt/bin/clang-format -style=LLVM a.cpp
const NamespaceName::VeryLongClassName &
NamespaceName::VeryLongClassName::myFunction() {
// do stuff
}

const NamespaceName::VeryLongClassName &NamespaceName::VeryLongClassName::
operator++() {
// do stuff
}
```
What was happening is that the split penalty before `operator` was being set to
a smaller value by a prior if block. Moved checks around to fix this and added a
regression test.

Reviewers: djasper

Reviewed By: djasper

Tags: #clang

Differential Revision: https://reviews.llvm.org/D57604

llvm-svn: 353033

show more ...

[clang-format] Fix line parsing for noexcept lambdas

Summary:
> $ echo "int c = [b]() mutable noexcept { return [&b] { return b++; }(); }();" |clang-format

```
int c = [b]() mutable noexcept {
re

[clang-format] Fix line parsing for noexcept lambdas

Summary:
> $ echo "int c = [b]() mutable noexcept { return [&b] { return b++; }(); }();" |clang-format

```
int c = [b]() mutable noexcept {
return [&b] { return b++; }();
}
();
```
with patch:
> $ echo "int c = [b]() mutable noexcept { return [&b] { return b++; }(); }();" |bin/clang-format
```
int c = [b]() mutable noexcept { return [&b] { return b++; }(); }();
```

Contributed by hultman.

Reviewers: benhamilton, jolesiak, klimek, Wizard

Reviewed By: benhamilton

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D56909

llvm-svn: 352622

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

[clang-format] Do not treat asm clobber [ as ObjCExpr, refined

Summary:
r346756 refined clang-format to not treat the `[` in `asm (...: [] ..)` as an
ObjCExpr. However that's not enough, as we might

[clang-format] Do not treat asm clobber [ as ObjCExpr, refined

Summary:
r346756 refined clang-format to not treat the `[` in `asm (...: [] ..)` as an
ObjCExpr. However that's not enough, as we might have a comma-separated list of
such clobbers as in the newly added test.
This updates the detection to instead look at the Line's first token being `asm`
and not mark `[`-s as ObjCExprs in this case.

Reviewers: djasper, benhamilton

Reviewed By: djasper, benhamilton

Subscribers: benhamilton, cfe-commits

Differential Revision: https://reviews.llvm.org/D54795

llvm-svn: 347465

show more ...

[clang-format] Do not treat the asm clobber [ as ObjCExpr

Summary:
The opening square of an inline asm clobber was being annotated as an ObjCExpr.
This caused, amongst other things, the ObjCGuesser

[clang-format] Do not treat the asm clobber [ as ObjCExpr

Summary:
The opening square of an inline asm clobber was being annotated as an ObjCExpr.
This caused, amongst other things, the ObjCGuesser to guess header files
containing that pattern as ObjC files.

Reviewers: benhamilton

Reviewed By: benhamilton

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D54111

llvm-svn: 346756

show more ...

Fix ClangFormat issue of recognizing ObjC subscript as C++ attributes when message target is a result of a C-style method.

Summary:
The issue is that for array subscript like:

```
arr[[Foo() bar]];

Fix ClangFormat issue of recognizing ObjC subscript as C++ attributes when message target is a result of a C-style method.

Summary:
The issue is that for array subscript like:

```
arr[[Foo() bar]];
```
ClangFormat will recognize it as C++11 attribute syntax and put a space between 'arr' and first '[', like:

```
arr [[Foo() bar]];
```

Now it is fixed. Tested with:
```
ninja FormatTests
```

Reviewers: benhamilton

Reviewed By: benhamilton

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D54288

llvm-svn: 346566

show more ...

[clang-format] tweaked another case of lambda formatting

Summary:
This is done in order to improve cases where the lambda's body is moved too far to the right. Consider the following snippet with co

[clang-format] tweaked another case of lambda formatting

Summary:
This is done in order to improve cases where the lambda's body is moved too far to the right. Consider the following snippet with column limit set to 79:

```
void f() {
leader::MakeThisCallHere(&leader_service_,
cq_.get(),
[this, liveness](const leader::ReadRecordReq& req,
std::function<void()> done) {
logger_->HandleReadRecord(
req, resp, std::move(done));
});

leader::MakeAnother(&leader_service_,
cq_.get(),
[this, liveness](const leader::ReadRecordReq& req,
std::function<void()> done) {
logger_->HandleReadRecord(
req, resp, std::move(done), a);
});
}
```

The tool favors extra indentation for the lambda body and so the code incurs extra wrapping and adjacent calls are indented to a different level. I find this behavior annoying and I'd like the tool to favor new lines and, thus, use the extra width.

The fix, reduced, brings the following formatting.

Before:

function(1,
[] {
DoStuff();
//
},
1);

After:

function(
1,
[] {
DoStuff();
//
},
1);

Refer to the new tests in FormatTest.cpp

Contributed by oleg.smolsky!

Reviewers: djasper, klimek, krasimir

Subscribers: cfe-commits, owenpan

Tags: #clang

Differential Revision: https://reviews.llvm.org/D52676

llvm-svn: 345753

show more ...