Summary:
This patch changes the structure for raw string formatting options by making it
language based (enumerate delimiters per language) as opposed to delimiter-based
(specify the language for a delimiter). The raw string formatting now uses an
appropriate style from the .clang-format file, if exists.
Reviewers: bkramer
Reviewed By: bkramer
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D42098
llvm-svn: 322634
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Summary: The original changes for ref qualifiers in rL272537 and rL272548 allowed function const+ref qualifier spacing to diverge from the spacing used for variables. It seems more consistent for `T const& x;` to match `void foo() const&;`.
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D34324
llvm-svn: 310544
This fixes a bug in `ENAS_DontAlign` (introduced in D32733) where blank lines had an EscapedNewlineColumn of 0, causing a subtraction to overflow when converted back to unsigned and leading to runaway memory allocation.
Differential Revision: https://reviews.llvm.org/D36019
llvm-svn: 310539
Summary:
Allow merging short case labels when they actually end with a comment
(like a comment after the ``break``) and when followed by switch-level
comments (e.g. aligned with next case):
switch(a) {
case 0: break; // comment at end of case
case 1: return value;
// comment related to next case
// comment related to next case
case 2:
}
Reviewers: krasimir, djasper
Reviewed By: krasimir
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D35557
llvm-svn: 309370
The goal of this commit is to fix clang-format so it does not merge tokens when
using the alternative spelling keywords. (eg: "not foo" should not become "notfoo")
The problem is that Preprocessor::HandleIdentifier used to drop the identifier info
from the token for these keyword. This means the first condition of
TokenAnnotator::spaceRequiredBefore is not met. We could add explicit check for
the spelling in that condition, but I think it is better to keep the IdentifierInfo
and handle the operator keyword explicitly when needed. That actually leads to simpler
code, and probably slightly more efficient as well.
Another side effect of this change is that __identifier(and) will now work as
one would expect, removing a FIXME from the MicrosoftExtensions.cpp test
Differential Revision: https://reviews.llvm.org/D35172
llvm-svn: 308008
Summary:
This patch fixes bug https://bugs.llvm.org/show_bug.cgi?id=3313: a comment line
was aligned with the next #ifdef even in the presence of an empty line between
them.
Reviewers: djasper, klimek
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D35296
llvm-svn: 307795
Summary:
This patch introduces a few extra BraceWrapping options, similar to
`SplitEmptyFunction`, to allow merging empty 'record' bodies (e.g.
class, struct, union and namespace):
* SplitEmptyClass
* SplitEmptyStruct
* SplitEmptyUnion
* SplitEmptyNamespace
The `SplitEmptyFunction` option name has also been simplified/
shortened (from `SplitEmptyFunctionBody`).
These options are helpful when the correspond AfterXXX option is
enabled, to allow merging the empty record:
class Foo
{};
In addition, this fixes an unexpected merging of short records, when
the AfterXXXX options are used, which caused to be formatted like
this:
class Foo
{ void Foo(); };
This is now properly formatted as:
class Foo
{
void Foo();
};
Reviewers: djasper, krasimir
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D34395
llvm-svn: 306874
Summary:
This patch tries to avoid binpacking when initializing lists/arrays, to allow things like:
static int types[] = {
registerType1(),
registerType2(),
registerType3(),
};
std::map<int, std::string> x = {
{ 0, "foo fjakfjaklf kljj" },
{ 1, "bar fjakfjaklf kljj" },
{ 2, "stuff fjakfjaklf kljj" },
};
This is similar to how dictionnaries are formatted, and actually corresponds to the same conditions: when initializing a container (and not just 'calling' a constructor).
Such formatting involves 2 things:
* Line breaks around the content of the block. This can be forced by adding a comma or comment after the last element
* Elements should not be binpacked
This patch considers the block is an initializer list if it either ends with a comma, or follows an assignment, which seems to provide a sensible approximation.
Reviewers: krasimir, djasper
Reviewed By: djasper
Subscribers: malcolm.parsons, klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D34238
llvm-svn: 306868
Summary:
This is the same as Inline, except it does not imply all empty
functions are merged: with this style, empty functions are merged only
if they also match the 'inline' criteria (i.e. defined in a class).
This is helpful to avoid inlining functions in implementations files.
Reviewers: djasper, krasimir
Reviewed By: djasper
Subscribers: klimek, rengolin, cfe-commits
Differential Revision: https://reviews.llvm.org/D34399
llvm-svn: 305912
Summary:
This fixes the missing space before the designated initializer when `Cpp11BracedListStyle=false` :
const struct A a = { .a = 1, .b = 2 };
^
Also, wrapping between opening brace and designated array initializers used to have an excessive penalty (like breaking between an expression and the subscript operator), leading to unexpected wrapping:
const struct Aaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaa =
{[1] = aaaaaaaaaaaaaaaaaaaaaaaaaaa,
[2] = bbbbbbbbbbbbbbbbbbbbbbbbbbb};
instead of:
const struct Aaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaa = {
[1] = aaaaaaaaaaaaaaaaaaaaaaaaaaa,
[2] = bbbbbbbbbbbbbbbbbbbbbbbbbbb};
Finally, designated array initializers are not binpacked, just like designated member initializers.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, krasimir, klimek
Differential Revision: https://reviews.llvm.org/D33491
llvm-svn: 305696
Fixes an issue where struct A { int X; }; would be broken onto multiple
lines, but typedef struct A { int X; } A2; was collapsed onto a single
line.
Patch by Jacob Bandes-Storch. Thank you.
llvm-svn: 305667
c++1z adds the following constructions to the language:
if constexpr (cond)
statement1;
else if constexpr (cond)
statement2;
else if constexpr (cond)
statement3;
else
statement4;
A first version of this was proposed in reviews.llvm.org/D26953 by
Francis Visoiu Mistrih, but never commited. This patch additionally
fixes the behavior when allowing short if statements on a single line
and was authored by Jacob Bandes-Storch. Thank you to both authors.
llvm-svn: 305666
Summary:
Add CompactNamespaces option, to pack namespace declarations on the
same line (somewhat similar to C++17 nested namespace definition).
With this option, consecutive namespace declarations are kept on the
same line:
namespace foo { namespace bar {
...
}} // namespace foo::bar
Reviewers: krasimir, djasper, klimek
Reviewed By: djasper
Subscribers: kimgr, cfe-commits, klimek
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D32480
llvm-svn: 305384
Summary:
This option supplements the AllowShortFunctionsOnASingleLine flag, to
merge empty function body at the beginning of the line: e.g. when the
function is not short-enough and breaking braces after function.
int f()
{}
Reviewers: krasimir, djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D33447
llvm-svn: 305272
Summary:
This option replaces the BreakConstructorInitializersBeforeComma option with an enum, thus introducing a mode where the colon stays on the same line as constructor declaration:
// When it fits on line:
Constructor() : initializer1(), initializer2() {}
// When it does not fit:
Constructor() :
initializer1(), initializer2()
{}
// When ConstructorInitializerAllOnOneLineOrOnePerLine = true:
Constructor() :
initializer1(),
initializer2()
{}
Reviewers: krasimir, djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D32479
llvm-svn: 303739
Summary:
Add option to customize the penalty for breaking assignment
This allows increasing the priority of the assignment, to prefer spliting
an operation instead of splitting the assignment, e.g. :
int a = bbbbbbbbbbbbbbbb +
cccccccccccccccc;
Reviewers: krasimir, djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D32477
llvm-svn: 303534
myFunction(param1, param2,);
For symmetry with other parenthesized lists ([...], {...}), clang-format should
wrap parenthesized lists one-per-line if they contain a trailing comma:
myFunction(
param1,
param2,
);
This is particularly useful in function declarations or calls with many
arguments, e.g. commonly in constructors.
Differential Revision: https://reviews.llvm.org/D33023
llvm-svn: 303049
DontAlign
This converts the clang-format option AlignEscapedNewlinesLeft from a
boolean to an enum, named AlignEscapedNewlines, with options Left (prev.
true), Right (prev. false), and a new option DontAlign.
When set to DontAlign, the backslashes are placed just after the last token in each line:
#define EXAMPLE \
do { \
int x = aaaaa; \
int b; \
int dddddddddd; \
} while (0)
Patch by jtbandes. Thank you!
llvm-svn: 302428
Before:
std::function<
LoooooooooooongTemplatedType<SomeType>*(
LooooooooooooooooooooongType
type)>
function;
After:
std::function<
LoooooooooooongTemplatedType<
SomeType>*(
LooooooooooooooooongType type)>
function;
clang-format generally avoids having lines like "SomeType>*(" as they
lead to parameter lists that don't belong together to be aligned. However, in
case it is better than the alternative, which can even be violating the column
limit.
llvm-svn: 301182
Summary: This patch replaces the boolean IncompleteFormat that is used to notify the client if an unrecoverable syntax error occurred by a struct that also contains a line number.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D32298
llvm-svn: 300985
