[clang-format] [NFC] Remove comment

Remove inaccurate comment that came in with r312125.

llvm-svn: 322448

[c++20] P0515R3: Parsing support and basic AST construction for operator <=>.

Adding the new enumerator forced a bunch more changes into this patch than I
would have liked. The -Wtautological-compar

[c++20] P0515R3: Parsing support and basic AST construction for operator <=>.

Adding the new enumerator forced a bunch more changes into this patch than I
would have liked. The -Wtautological-compare warning was extended to properly
check the new comparison operator, clang-format needed updating because it uses
precedence levels as weights for determining where to break lines (and several
operators increased their precedence levels with this change), thread-safety
analysis needed changes to build its own IL properly for the new operator.

All "real" semantic checking for this operator has been deferred to a future
patch. For now, we use the relational comparison rules and arbitrarily give
the builtin form of the operator a return type of 'void'.

llvm-svn: 320707

show more ...

Better trade-off for excess characters vs. staying within the column limits.

When we break a long line like:
Column limit: 21
|
// foo foo foo foo foo foo foo foo foo foo foo

Better trade-off for excess characters vs. staying within the column limits.

When we break a long line like:
Column limit: 21
|
// foo foo foo foo foo foo foo foo foo foo foo foo

The local decision when to allow protruding vs. breaking can lead to this
outcome (2 excess characters, 2 breaks):
// foo foo foo foo foo
// foo foo foo foo foo
// foo foo

While strictly staying within the column limit leads to this strictly better
outcome (fully below the column limit, 2 breaks):
// foo foo foo foo
// foo foo foo foo
// foo foo foo foo

To get an optimal solution, we would need to consider all combinations of excess
characters vs. breaking for all lines, but that would lead to a significant
increase in the search space of the algorithm for little gain.

Instead, we blindly try both approches and·select the one that leads to the
overall lower penalty.

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

llvm-svn: 319541

show more ...

Restructure how we break tokens.

This fixes some bugs in the reflowing logic and splits out the concerns
of reflowing from BreakableToken.

Things to do after this patch:
- Refactor the breakProtrud

Restructure how we break tokens.

This fixes some bugs in the reflowing logic and splits out the concerns
of reflowing from BreakableToken.

Things to do after this patch:
- Refactor the breakProtrudingToken function possibly into a class, so we
can split it up into methods that operate on the common state.
- Optimize whitespace compression when reflowing by using the next possible
split point instead of the latest possible split point.
- Retry different strategies for reflowing (strictly staying below the
column limit vs. allowing excess characters if possible).

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

llvm-svn: 319314

show more ...

clang-format: remove trailing lines in lamdas and arrow functions.

Summary:
clang-format already removes empty lines at the beginning & end of
blocks:

int x() {

foo(); // lines before a

clang-format: remove trailing lines in lamdas and arrow functions.

Summary:
clang-format already removes empty lines at the beginning & end of
blocks:

int x() {

foo(); // lines before and after will be removed.

}

However because lamdas and arrow functions are parsed as expressions,
the existing logic to remove empty lines in UnwrappedLineFormatter
doesn't handle them.

This change special cases arrow functions in ContinuationIndenter to
remove empty lines:

x = []() {

foo(); // lines before and after will now be removed.

};

Reviewers: djasper

Subscribers: klimek, cfe-commits

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

llvm-svn: 318537

show more ...

Implement more accurate penalty & trade-offs while breaking protruding tokens.

For each line that we break in a protruding token, compute whether the
penalty of breaking is actually larger than the

Implement more accurate penalty & trade-offs while breaking protruding tokens.

For each line that we break in a protruding token, compute whether the
penalty of breaking is actually larger than the penalty of the excess
characters. Only break if that is the case.

llvm-svn: 318515

show more ...

Refactor ContinuationIndenter's breakProtrudingToken logic.

Create more orthogonal pieces. The restructuring made it easy to try out
several alternatives to D33589, and while none of the alternative

Refactor ContinuationIndenter's breakProtrudingToken logic.

Create more orthogonal pieces. The restructuring made it easy to try out
several alternatives to D33589, and while none of the alternatives
turned out to be the right solution, the underlying simplification of
the structure is helpful.

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

llvm-svn: 318141

show more ...

[clang-format] Handle unary operator overload with arguments and specifiers

Before:
int operator++(int)noexcept;

After:
int operator++(int) noexcept;

Patch by Igor Sugak. Thank you!

llvm-svn:

[clang-format] Handle unary operator overload with arguments and specifiers

Before:
int operator++(int)noexcept;

After:
int operator++(int) noexcept;

Patch by Igor Sugak. Thank you!

llvm-svn: 317473

show more ...

[clang-format] Handle CRLF correctly when formatting escaped newlines

Subscribers: klimek

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

Contributed by @peterbudai!

llvm-svn: 316910

[clang-format] Format raw string literals

Summary:
This patch adds raw string literal formatting.

Reviewers: djasper, klimek

Reviewed By: klimek

Subscribers: klimek, mgorny

Differential Revision

[clang-format] Format raw string literals

Summary:
This patch adds raw string literal formatting.

Reviewers: djasper, klimek

Reviewed By: klimek

Subscribers: klimek, mgorny

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

llvm-svn: 316903

show more ...

[clang-format] Fix regression about short functions after #else

Summary:
This patch fixes a regression introduced in r312904, where the formatter confuses
the `else` in `#else` with an `else` of an

[clang-format] Fix regression about short functions after #else

Summary:
This patch fixes a regression introduced in r312904, where the formatter confuses
the `else` in `#else` with an `else` of an `if-else` statement.
For example, formatting this code with google style
```
#ifdef A
int f() {}
#else
int f() {}
#endif
```
resulted in
```
#ifdef A
int f() {}
#else
int f() {
}
#endif
```

Reviewers: sammccall

Reviewed By: sammccall

Subscribers: klimek, cfe-commits

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

llvm-svn: 314683

show more ...

[clang-format] Fix FixNamespaceComments when BraceWrapping AfterNamespace is true.

Summary:
NamespaceEndCommentsFixer did not fix namespace comments when the brace opening the namespace was not on t

[clang-format] Fix FixNamespaceComments when BraceWrapping AfterNamespace is true.

Summary:
NamespaceEndCommentsFixer did not fix namespace comments when the brace opening the namespace was not on the same line as the "namespace" keyword.
It occurs in Allman, GNU and Linux styles and whenever BraceWrapping.AfterNamespace is true.

Before:
```lang=cpp
namespace a
{
void f();
void g();
}
```

After:
```lang=cpp
namespace a
{
void f();
void g();
} // namespace a
```

Reviewers: krasimir

Reviewed By: krasimir

Subscribers: klimek, cfe-commits

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

llvm-svn: 314279

show more ...

[clang-format] Adjust space around &/&& of structured bindings

Keep space before or after the &/&& tokens, but not both. For example,
auto [x,y] = a;
auto &[xr, yr] = a; // LLVM style
auto& [x

[clang-format] Adjust space around &/&& of structured bindings

Keep space before or after the &/&& tokens, but not both. For example,
auto [x,y] = a;
auto &[xr, yr] = a; // LLVM style
auto& [xr, yr] = a; // google style

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

llvm-svn: 314264

show more ...

Fix clang-format's detection of structured bindings.

Correctly determine when [ is part of a structured binding instead of a
lambda.

To be able to reuse the implementation already available, this p

Fix clang-format's detection of structured bindings.

Correctly determine when [ is part of a structured binding instead of a
lambda.

To be able to reuse the implementation already available, this patch also:
- sets the Previous link of FormatTokens in the UnwrappedLineParser
- moves the isCppStructuredBinding function into FormatToken

Before:
auto const const &&[x, y] { A *i };

After:
auto const const && [x, y]{A * i};

Fixing formatting of the type of the structured binding is still missing.

llvm-svn: 313742

show more ...

Fix formatting of lambda introducers with initializers.

Most of the work was already done when we introduced a look-behind based
lambda introducer detection.

This patch finishes the transition by c

Fix formatting of lambda introducers with initializers.

Most of the work was already done when we introduced a look-behind based
lambda introducer detection.

This patch finishes the transition by completely relying on the simple
lambda introducer detection and simply recursing into normal
brace-parsing code to parse until the end of the introducer.

This fixes initializers in lambdas, including nested lambdas.

Before:
auto a = [b = [c = 42]{}]{};
auto b = [c = &i + 23]{};

After:
auto a = [b = [c = 42] {}] {};
auto b = [c = &i + 23] {};

llvm-svn: 313622

show more ...

[clang-format] New flag - BraceWrapping.AfterExternBlock

Summary:
Bug: https://bugs.llvm.org/show_bug.cgi?id=34016 - **"extern C part"**

**Problem:**

Due to the lack of "brace wrapping extern" fla

[clang-format] New flag - BraceWrapping.AfterExternBlock

Summary:
Bug: https://bugs.llvm.org/show_bug.cgi?id=34016 - **"extern C part"**

**Problem:**

Due to the lack of "brace wrapping extern" flag, clang format does parse the block after **extern** keyword moving the opening bracket to the header line always!

**Patch description:**

A new style added, new configuration flag - **BraceWrapping.AfterExternBlock** that allows us to decide whether we want a break before brace or not.

Reviewers: djasper, krasimir

Reviewed By: krasimir

Subscribers: klimek, cfe-commits

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

Contributed by @PriMee!

llvm-svn: 313354

show more ...

[clang-format] Fixed one-line if statement

Summary:
**Short overview:**

Fixed bug: https://bugs.llvm.org/show_bug.cgi?id=34001
Clang-format bug resulting in a strange behavior of control statements

[clang-format] Fixed one-line if statement

Summary:
**Short overview:**

Fixed bug: https://bugs.llvm.org/show_bug.cgi?id=34001
Clang-format bug resulting in a strange behavior of control statements short blocks. Different flags combinations do not guarantee expected result. Turned on option AllowShortBlocksOnASingleLine does not work as intended.

**Description of the problem:**

Cpp source file UnwrappedLineFormatter does not handle AllowShortBlocksOnASingleLine flag as it should. Putting a single-line control statement without any braces, clang-format works as expected (depending on AllowShortIfStatementOnASingleLine or AllowShortLoopsOnASingleLine value). Putting a single-line control statement in braces, we can observe strange and incorrect behavior.
Our short block is intercepted by tryFitMultipleLinesInOne function. The function returns a number of lines to be merged. Unfortunately, our control statement block is not covered properly. There are several if-return statements, but none of them handles our block. A block is identified by the line first token and by left and right braces. A function block works as expected, there is such an if-return statement doing proper job. A control statement block, from the other hand, falls into strange conditional construct, which depends on BraceWrapping.AfterFunction flag (with condition that the line’s last token is left brace, what is possible in our case) or goes even further. That should definitely not happen.

**Description of the patch:**

By adding three different if statements, we guarantee that our short control statement block, however it looks like (different brace wrapping flags may be turned on), is handled properly and does not fall into wrong conditional construct. Depending on appropriate options we return either 0 (when something disturbs our merging attempt) or let another function (tryMergeSimpleBlock) take the responsibility of returned result (number of merged lines). Nevertheless, one more correction is required in mentioned tryMergeSimpleBlock function. The function, previously, returned either 0 or 2. The problem was that this did not handle the case when our block had the left brace in a separate line, not the header one. After change, after adding condition, we return the result compatible with block’s structure. In case of left brace in the header’s line we do everything as before the patch. In case of left brace in a separate line we do the job similar to the one we do in case of a “non-header left brace” function short block. To be precise, we try to merge the block ignoring the header line. Then, if success, we increment our returned result.

**After fix:**

**CONFIG:**
```
AllowShortBlocksOnASingleLine: true
AllowShortIfStatementsOnASingleLine: true
BreakBeforeBraces: Custom
BraceWrapping: {
AfterClass: true, AfterControlStatement: true, AfterEnum: true, AfterFunction: true, AfterNamespace: false, AfterStruct: true, AfterUnion: true, BeforeCatch: true, BeforeElse: true
}
```
**BEFORE:**
```
if (statement) doSomething();
if (statement) { doSomething(); }
if (statement) {
doSomething();
}
if (statement)
{
doSomething();
}
if (statement)
doSomething();
if (statement) {
doSomething1();
doSomething2();
}
```
**AFTER:**
```
if (statement) doSomething();
if (statement) { doSomething(); }
if (statement) { doSomething(); }
if (statement) { doSomething(); }
if (statement) doSomething();
if (statement)
{
doSomething1();
doSomething2();
}
```

Contributed by @PriMee!

Reviewers: krasimir, djasper

Reviewed By: krasimir

Subscribers: cfe-commits, klimek

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

llvm-svn: 312904

show more ...

[clang-format] Add support for C++17 structured bindings.

Summary:
Before:
```
auto[a, b] = f();
```

After:
```
auto [a, b] = f();
```
or, if SpacesInSquareBrackets is true:
```
auto [

[clang-format] Add support for C++17 structured bindings.

Summary:
Before:
```
auto[a, b] = f();
```

After:
```
auto [a, b] = f();
```
or, if SpacesInSquareBrackets is true:
```
auto [ a, b ] = f();
```

Reviewers: djasper

Reviewed By: djasper

Subscribers: cfe-commits, klimek

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

llvm-svn: 312723

show more ...

clang-format: Fix indentation of macros in include guards (after r312125).

Before:
#ifndef A_H
#define A_H

#define A() \
int i; \
int j;

#endif // A_H

After:
#ifndef A_H
#defin

clang-format: Fix indentation of macros in include guards (after r312125).

Before:
#ifndef A_H
#define A_H

#define A() \
int i; \
int j;

#endif // A_H

After:
#ifndef A_H
#define A_H

#define A() \
int i; \
int j;

#endif // A_H

llvm-svn: 312484

show more ...

clang-format: Fix formatting of for loops with multiple increments.

This fixes llvm.org/PR34366.

llvm-svn: 312437

Disable clang-format's MemoizationTest as it becomes prohibitive with EXPENSIVE_CHECKS

EXPENSIVE_CHECKS enables libstdc++'s library consistency checks, which
includes checking the container passed t

Disable clang-format's MemoizationTest as it becomes prohibitive with EXPENSIVE_CHECKS

EXPENSIVE_CHECKS enables libstdc++'s library consistency checks, which
includes checking the container passed to std::priority_queue for its
well-formedness. This makes the clang-format memoization too expensive,
so disable it.

(it's a necessary feature of libstdc++'s consistency checks that it
ruins the required scalability of C++ standard library features - so
these workarounds are to be expected if a test ever tries to test
scalability in some way, like this test does)

llvm-svn: 312268

show more ...

clang-format: Add preprocessor directive indentation

Summary:
This is an implementation for [bug 17362](https://bugs.llvm.org/attachment.cgi?bugid=17362) which adds support for indenting preprocesso

clang-format: Add preprocessor directive indentation

Summary:
This is an implementation for [bug 17362](https://bugs.llvm.org/attachment.cgi?bugid=17362) which adds support for indenting preprocessor statements inside if/ifdef/endif. This takes previous work from fmauch (https://github.com/fmauch/clang/tree/preprocessor_indent) and makes it into a full feature.
The context of this patch is that I'm a VMware intern, and I implemented this because VMware needs the feature. As such, some decisions were made based on what VMware wants, and I would appreciate suggestions on expanding this if necessary to use-cases other people may want.

This adds a new enum config option, `IndentPPDirectives`. Values are:

* `PPDIS_None` (in config: `None`):
```
#if FOO
#if BAR
#include <foo>
#endif
#endif
```
* `PPDIS_AfterHash` (in config: `AfterHash`):
```
#if FOO
# if BAR
# include <foo>
# endif
#endif
```
This is meant to work whether spaces or tabs are used for indentation. Preprocessor indentation is independent of indentation for non-preprocessor lines.

Preprocessor indentation also attempts to ignore include guards with the checks:
1. Include guards cover the entire file
2. Include guards don't have `#else`
3. Include guards begin with
```
#ifndef <var>
#define <var>
```

This patch allows `UnwrappedLineParser::PPBranchLevel` to be decremented to -1 (the initial value is -1) so the variable can be used for indent tracking.

Defects:
* This patch does not handle the case where there's code between the `#ifndef` and `#define` but all other conditions hold. This is because when the #define line is parsed, `UnwrappedLineParser::Lines` doesn't hold the previous code line yet, so we can't detect it. This is out of the scope of this patch.

* This patch does not handle cases where legitimate lines may be outside an include guard. Examples are `#pragma once` and `#pragma GCC diagnostic`, or anything else that does not change the meaning of the file if it's included multiple times.

* This does not detect when there is a single non-preprocessor line in front of an include-guard-like structure where other conditions hold because `ScopedLineState` hides the line.

* Preprocessor indentation throws off `TokenAnnotator::setCommentLineLevels` so the indentation of comments immediately before indented preprocessor lines is toggled on each run. Fixing this issue appears to be a major change and too much complexity for this patch.

Contributed by @euhlmann!

Reviewers: djasper, klimek, krasimir

Reviewed By: djasper, krasimir

Subscribers: krasimir, mzeren-vmw, cfe-commits

Tags: #clang

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

llvm-svn: 312125

show more ...

[clang-format] Do not format likely xml

Summary:
This patch detects the leading '<' in likely xml files and stops formatting in
that case. A recent use of a Qt xml file with a .ts extension triggere

[clang-format] Do not format likely xml

Summary:
This patch detects the leading '<' in likely xml files and stops formatting in
that case. A recent use of a Qt xml file with a .ts extension triggered this:
http://doc.qt.io/qt-4.8/linguist-ts-file-format.html

Reviewers: djasper

Reviewed By: djasper

Subscribers: sammccall, cfe-commits, klimek

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

llvm-svn: 311999

show more ...

[clang-format] Fixed typedef enum brace wrapping

Summary:
Bug: https://bugs.llvm.org/show_bug.cgi?id=34016 - **Typedef enum part**

**Problem:**

Clang format does not allow the flag **BraceWrapping

[clang-format] Fixed typedef enum brace wrapping

Summary:
Bug: https://bugs.llvm.org/show_bug.cgi?id=34016 - **Typedef enum part**

**Problem:**

Clang format does not allow the flag **BraceWrapping.AfterEnum** control the case when our **enum** is preceded by **typedef** keyword (what is common in C language).

**Patch description:**

Added case to the **"AfterEnum"** flag when our enum does not start a line - is preceded by **typedef** keyword.

**After fix:**

**CONFIG:**
```
BreakBeforeBraces: Custom
BraceWrapping: {
AfterClass: true, AfterControlStatement: true, AfterEnum: true, AfterFunction: true, AfterNamespace: false, AfterStruct: true, AfterUnion: true, BeforeCatch: true, BeforeElse: true
}
```

**BEFORE:**
```
typedef enum
{
a,
b,
c
} SomeEnum;
```

**AFTER:**

```
typedef enum
{
a,
b,
c
} SomeEnum;
```

Contributed by @PriMee!

Reviewers: krasimir, djasper

Reviewed By: djasper

Subscribers: cfe-commits, klimek

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

llvm-svn: 311998

show more ...

[Format] Invert nestingAndIndentLevel pair in WhitespaceManager used for
alignments

Indent should be compared before nesting level to determine if a token
is on the same scope as the one we align wi

[Format] Invert nestingAndIndentLevel pair in WhitespaceManager used for
alignments

Indent should be compared before nesting level to determine if a token
is on the same scope as the one we align with. Because it was inverted,
clang-format sometimes tried to align tokens with tokens from outer
scopes, causing the assert(Shift >= 0) to fire.

This fixes bug #33507. Patch by Beren Minor, thank you!

llvm-svn: 311792

show more ...