The rewrite facility's footprint is small so it's not worth going to these
lengths to support disabling at configure time, particularly since key compiler
features now depend on it.
Meanwhile the Objective-C rewriters have been moved under the
ENABLE_CLANG_ARCMT umbrella for now as they're comparatively heavy and still
potentially worth excluding from lightweight builds.
Tests are now passing with any combination of feature flags. The flags
historically haven't been tested by LLVM's build servers so caveat emptor.
llvm-svn: 213171
Now, this can be properly formatted:
static_cast<A< //
B> *>( //
);
Before, clang-format could end up, not formatting the code at all.
llvm-svn: 213055
Though not completely identical, make former
IndentFunctionDeclarationAfterType change this flag for backwards
compatibility (it is somewhat close in meaning and better the err'ing on
an unknown config flag).
llvm-svn: 212597
Key changes:
- Correctly (well ...) distinguish function declarations and variable
declarations with ()-initialization.
- Don't indent when breaking function declarations/definitions after the
return type.
- Indent variable declarations and typedefs when breaking after the
type.
This fixes llvm.org/PR17999.
llvm-svn: 212591
Upon encountering a binary operator inside parentheses, assume that the
parentheses contain an expression.
Before:
MACRO('0' <= c&& c <= '9');
After:
MACRO('0' <= c && c <= '9');
llvm-svn: 212040
This worked initially but was broken by r210887.
Before:
function outer1(a, b) {
function inner1(a, b) { return a; } inner1(a, b);
} function outer2(a, b) { function inner2(a, b) { return a; } inner2(a, b); }
After:
function outer1(a, b) {
function inner1(a, b) { return a; }
inner1(a, b);
}
function outer2(a, b) {
function inner2(a, b) { return a; }
inner2(a, b);
}
Thanks to Adam Strzelecki for working on this.
llvm-svn: 212038
Before (JavaScript example, but can extend to other languages):
return {
a: 'E',
b: function() {
return function() {
f(); // This is wrong.
};
}
};
After:
return {
a: 'E',
b: function() {
return function() {
f(); // This is better.
};
}
};
llvm-svn: 210334
These are commonly used to structure things like enums or long braced
lists. There doesn't seem to be a good reason to have the behavior in
such structures be different from the behavior between statements.
llvm-svn: 210183
There is a pattern where evaluation order is used as control flow.
This patch special-cases a commonly occuring version of this pattern.
Before:
Aaaaa *aaa = nullptr;
// ...
aaa &&aaa->f();
After:
Aaaaa *aaa = nullptr;
// ...
aaa && aaa->f();
llvm-svn: 210017
Before (with just the right line length:
switch (a) {
case some_namespace::some_constant
:
return;
}
After:
switch (a) {
case some_namespace::
some_constant:
return;
}
llvm-svn: 209725
Before:
template <int> struct A4 { A4() { }
};
After:
template <int i> struct A4 {
A4() {}
};
This fixes llvm.org/PR19813 (at least the part that isn't working as
intended).
llvm-svn: 209438
Before:
var literal = 'hello ' + 'world';
After:
var literal = 'hello ' +
'world';
There is no reason to concatenated two string literals with a '+' unless
the line break is intended.
llvm-svn: 209413
Before:
int i{a *b};
After:
int i{a * b};
Also fix unrelated issue where braced init lists were counted as blocks
and prevented single-line functions.
llvm-svn: 209412
If simple (one-statement) blocks can be inlined, the length needs to be
calculated correctly.
Before (in JavaScript but this also affects lambdas, etc.):
var x = {
valueOf: function() { return 1; }
};
After:
var x = {valueOf: function() { return 1; }};
llvm-svn: 209410
So that JS functions can also be merged into a single line.
Before:
var func = function() {
return 1;
};
After:
var func = function() { return 1; };
llvm-svn: 208176
Before:
goog.scope(function() {
var x = a.b;
var y = c.d;
}); // goog.scope
After:
goog.scope(function() {
var x = a.b;
var y = c.d;
}); // goog.scope
llvm-svn: 208088
Before:
#ifdef _DEBUG
int foo( int i = 0 )
#else
int foo( int i = 5 )
#endif { return i; }
After:
#ifdef _DEBUG
int foo( int i = 0 )
#else
int foo( int i = 5 )
#endif
{
return i;
}
llvm-svn: 207958
definition below all of the header #include lines, clang edition.
If you want more details about this, you can see some of the commits to
Debug.h in LLVM recently. This is just the clang section of a cleanup
I've done for all uses of DEBUG_TYPE in LLVM.
llvm-svn: 206849
Summary:
This patch ensures that the lines of the block comments retain relative
column offsets. In order to do this WhitespaceManager::Changes representing
continuation of block comments keep a pointer on the change representing the
whitespace change before the block comment, and a relative column offset to this
change, so that the correct column can be reconstructed at the end of alignment
process.
Fixes http://llvm.org/PR19325
Reviewers: djasper
Reviewed By: djasper
CC: cfe-commits, klimek
Differential Revision: http://reviews.llvm.org/D3408
llvm-svn: 206472
With BinPackParameters=false and Cpp11BracedListStyle=true (i.e. mostly
for Chromium):
Before:
const Aaaaaa aaaaa = {aaaaa, bbbbb, ccccc, ddddd, eeeee, ffffff,
ggggg, hhhhhh, iiiiii, jjjjjj, kkkkkk};
After:
const Aaaaaa aaaaa = {aaaaa,
bbbbb,
ccccc,
ddddd,
eeeee,
ffffff,
ggggg,
hhhhhh,
iiiiii,
jjjjjj,
kkkkkk};
This fixes llvm.org/PR19359. I am not sure we'll want this in all cases
in the long run, but I'll guess we'll get feedback on that.
llvm-svn: 206458
This is similar to how we treat assignments and seems to be generally
desirable.
Before:
llvm::errs() << aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaaaaaaaaaa,
aaaaaaaaaaaaaaaaaaaaaaaaaaaa);
After:
llvm::errs() << aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaaaaaaaaaa);
llvm-svn: 206384
Also removed spaces before colons as they don't seem to be used
frequently.
Before:
optional int32 b = 2
[(foo_options) = {aaaaaaaaaaaaaaaaaaa : 123 bbbbbbbbbbbbbbbbbbbbbbbb :
"baz"}];
After:
optional int32 b = 2 [(foo_options) = {aaaaaaaaaaaaaaaaaaa: 123,
bbbbbbbbbbbbbbbbbbbbbbbb:"baz"}];
llvm-svn: 206269
Before:
if (aaaaaaaa && bbbbbbbbbbbbbbb // need to wrap
== cccccccccccccc) ...
After:
if (aaaaaaaa
&& bbbbbbbbbbbbbbb // need to wrap
== cccccccccccccc) ...
The same rule has already be implemented for BreakBeforeBinaryOperators
set to false in r205527.
llvm-svn: 206159
Now correctly formats:
{
int a;
void f() {
callme(some(parameter1,
<<<<<<< text by the vcs
parameter2),
||||||| text by the vcs
parameter2),
parameter3,
======= text by the vcs
parameter2, parameter3),
>>>>>>> text by the vcs
otherparameter);
}
}
llvm-svn: 206157
More precisely keep all short annotations (<10 characters) on the same
line if possible. Previously, clang-format would only prefer to do so
for "const", "override" and "final". However, it seems to be generally
preferable, especially because some codebases have to wrap those in
macros for backwards compatibility.
Before:
void someLongFunction(int someLongParameter)
OVERRIDE {}
After:
void someLongFunction(
int someLongParameter) OVERRIDE {}
This fixes llvm.org/PR19363.
llvm-svn: 205845
Before AllowShortFunctionsOnASingleLine could either be true, merging
all functions, or false, merging no functions. This patch adds a third
value "Inline", which can be used to only merge short functions defined
inline in a class, i.e.:
void f() {
return 42;
}
class C {
void f() { return 42; }
};
llvm-svn: 205760
Don't allow the RHS of an operator to be split over multiple
lines unless there is a line-break right after the operator.
Before:
if (aaaa && bbbbb || // break
cccc) {
}
After:
if (aaaa &&
bbbbb || // break
cccc) {
}
In most cases, this seems to increase readability.
llvm-svn: 205527
While these might make sense for some rule (e.g. break after multi-line
operand), they generally appear ugly and confusing.
Before:
fffffffffff(R\"x(
multiline raw string literal xxxxxxxxxxxxxx
)x\" + bbbbbb)
After:
fffffffffff(R\"x(
multiline raw string literal xxxxxxxxxxxxxx
)x\" +
bbbbbb)
llvm-svn: 204937
Due to not resetting the fake rparen data on the token when iterating
over annotated lines, we would pop the last element of the paren stack.
This patch fixes the underlying root cause, and makes the code more
robust against similar problems in the future:
- reset the first token when iterating on the same annotated lines due
to preprocessor branches
- never pop the last element from the paren stack, so we do not crash,
but rather incorrectly format
- add assert()s so we can figure out if our assumptions are violated
llvm-svn: 204140
This was leading to bad formatting, e.g.:
Before:
f(^{
@autoreleasepool {
if (a) {
g();
}
}
});
After:
f(^{
@autoreleasepool {
if (a) {
g();
}
}
});
llvm-svn: 203777
Before:
auto aaaaaaaa = [](int i, // break
int j)
-> int {
return fffffffffffffffffffffffffffffffffffffff(i * j);
};
After:
auto aaaaaaaa = [](int i, // break
int j) -> int {
return fffffffffffffffffffffffffffffffffffffff(i * j);
};
llvm-svn: 203562
init list formatting. This suggestion has now gone into the LLVM coding
standards, and is particularly relevant now that we're using C++11.
Updated a really ridiculous number of tests to reflect this change.
llvm-svn: 202637
Generally people seem to prefer wrapping the first function parameter
over wrapping the trailing tokens "const", "override" and "final". This
does not extend to function-like annotations and probably not to other
non-standard annotations.
Before:
void someLongFunction(int SomeLongParameter)
const { ... }
After:
void someLongFunction(
int SomeLongParameter) const { ... }
llvm-svn: 201504
Before:
auto result = SomeObject
// Calling someFunction on SomeObject
.someFunction();
After:
auto result = SomeObject
// Calling someFunction on SomeObject
.someFunction();
llvm-svn: 201138
It seems like most people see unary operators more like part of the
subsequent identifier and find relative indentation odd.
Before:
aaaaaaaaaa(!aaaaaaaaaa( // break
aaaaa));
After:
aaaaaaaaaa(!aaaaaaaaaa( // break
aaaaa));
llvm-svn: 200840
Before:
typedef NS_ENUM(NSInteger, MyType) {
/// Information about someDecentlyLongValue.
someDecentlyLongValue,
/// Information about anotherDecentlyLongValue.
anotherDecentlyLongValue,
/// Information about aThirdDecentlyLongValue.
aThirdDecentlyLongValue};
After:
typedef NS_ENUM(NSInteger, MyType) {
/// Information about someDecentlyLongValue.
someDecentlyLongValue,
/// Information about anotherDecentlyLongValue.
anotherDecentlyLongValue,
/// Information about aThirdDecentlyLongValue.
aThirdDecentlyLongValue
};
llvm-svn: 200469
Mozilla and WebKit seem to use a space after @property (verified by
grepping their codebases) so we turn this on there as well.
Change by Christian Legnitto. Thank you!
llvm-svn: 200320
This was done when we were not able to parse lambdas to handle some
edge cases for block formatting different in return statements, but is
not necessary any more.
llvm-svn: 199982
Before:
std::unique_ptr<int[]> foo() {}
After:
std::unique_ptr<int []> foo() {}
Also, the formatting could go severely wrong after such a function
before.
llvm-svn: 199817
The author might be missing the "#" or these might be protocol buffer
definitions. Either way, we should not break the line or the string.
There don't seem to be other valid use cases.
llvm-svn: 199501
We cannot simply change the start column to accomodate for the @ in an
ObjC string literal as that will make clang-format happily violate the
column limit.
Use a different workaround instead. However, a better long-term
solution might be to join the @ and the rest of the literal into a
single token.
llvm-svn: 199198
Before:
SomeThing // break
.SomeFunction( // break
param);
After:
SomeThing // break
.SomeFunction( // break
param);
Seems to be more common in editors and codebases I have looked at.
llvm-svn: 199105
Before:
SomeMap[std::pair(aaaaaaaaaaaa, bbbbbbbbbbbbbbb)]
.insert(ccccccccccccccccccccccc);
After:
SomeMap[std::pair(aaaaaaaaaaaa, bbbbbbbbbbbbbbb)].insert(
ccccccccccccccccccccccc);
This seems to be about 3:1 more common in Google and Chromium style and I found
only a handful of instances inside the LLVM codebase.
llvm-svn: 198924
While it is allowed to not have an @ on subsequent lines, it seems
general practice to add them. If undesired, the code author can easily
remove them again and clang-format won't re-add them.
llvm-svn: 198871
Before:
#pragma mark Any non - hyphenated or hyphenated string(including parentheses).
After:
#pragma mark Any non-hyphenated or hyphenated string (including parentheses).
llvm-svn: 198870
- Format a braced list with one element per line if it has nested
braced lists.
- Use a column layout only when the list has 6+ elements (instead of the
current 4+ elements).
llvm-svn: 198869
encodes the canonical rules for LLVM's style. I noticed this had drifted
quite a bit when cleaning up LLVM, so wanted to clean up Clang as well.
llvm-svn: 198686
Before:
enum ShortEnum {
A,
B,
C
};
After:
enum ShortEnum { A, B, C };
This seems to be the predominant choice in LLVM/Clang as well as in
Google style.
llvm-svn: 198558
A comment following the "{" of a braced list seems to almost always
refer to the first element of the list and thus should be aligned
to it.
Before (with Cpp11 braced list style):
SomeFunction({ // Comment 1
"first entry",
// Comment 2
"second entry"});
After:
SomeFunction({// Comment 1
"first entry",
// Comment 2
"second entry"});
llvm-svn: 197725
Unexpectedly, it seems that people commonly know what they were doing
when writing a comment.
Also, being more conservative about comment breaking has the advantage
of giving more flexibility. If a linebreak within the comment can
improve formatting, the author can add it (after which clang-format
won't undo it). There is no way to override clang-format's behavior if
it breaks a comment.
llvm-svn: 197698
Before:
aaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa)
.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
aaaaaaaaaa = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa)
.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa();
After:
aaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa)
.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
aaaaaaaaaa = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa)
.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa();
Probably still not ideal, but should be a step into the right direction.
llvm-svn: 197557
Formatting this:
void f() { // 1 space initial indent.
int i;
#define A \
int i; \
int j;
int k; // Format this line.
}
void f() {
#define A 1 // Format this line.
}
Before:
void f() { // 1 space initial indent.
int i;
#define A \
int i; \
int j;
int k; // Format this line.
}
void f() {
#define A 1 // Format this line.
}
After:
void f() { // 1 space initial indent.
int i;
#define A \
int i; \
int j;
int k; // Format this line.
}
void f() {
#define A 1 // Format this line.
}
llvm-svn: 197494
BreakConstructorInitializersBeforeComma is true.
This option is used in WebKit style, so this also ensures initializer lists are
not put on a single line, as per the WebKit coding guidelines.
Patch by Florian Sowade!
llvm-svn: 197386
Especially try to keep existing line breaks before raw string literals,
as the code author might have aligned content to it.
Thereby, clang-format now keeps things like:
parseStyle(R"(
BasedOnStyle: Google,
ColumnLimit: 100)");
parseStyle(
R"(BasedOnStyle: Google,
ColumnLimit: 100)");
llvm-svn: 197368
Summary:
Added BraceBreakingStyle::BS_GNU. I'm not sure about the correctness of
static initializer formatting, but compound statements should be fine.
Reviewers: djasper
Reviewed By: djasper
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D2372
llvm-svn: 197138
Summary:
This still misses a few important features, so there's no mention of
this style in the help message, but a few style rules are implemented.
Reviewers: djasper
Reviewed By: djasper
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D2371
llvm-svn: 196928
Summary:
Allow predefined styles to define different options for different
languages so that one can run:
clang-format -style=google file1.cpp file2.js
or use a single .clang-format file with "BasedOnStyle: Google" for both c++ and
JS files.
Added Google style for JavaScript with "BreakBeforeTernaryOperators" set to
false.
Reviewers: djasper
Reviewed By: djasper
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D2364
llvm-svn: 196909
Summary:
The rule from the GNU style states:
"We find it easier to read a program when it has spaces before the open-parentheses and after the commas."
http://www.gnu.org/prep/standards/standards.html#index-spaces-before-open_002dparen
This patch makes clang-format adds an option to put spaces before almost all open parentheses, except the cases, where different behavior is dictated by the style rules or language syntax:
* preprocessor:
** function-like macro definitions can't have a space between the macro name and the parenthesis;
** `#if defined(...)` can have a space, but it seems, that it's more frequently used without a space in GCC, for example;
* never add spaces after unary operators;
* adding spaces between two opening parentheses is controlled with the `SpacesInParentheses` option;
* never add spaces between `[` and `(` (there's no option yet).
Reviewers: djasper
Reviewed By: djasper
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D2326
llvm-svn: 196901
Summary:
Allow tryFitMultipleLinesInOne join unwrapped lines when
ContinuationIndenter::mustBreak doesn't agree. But don't merge any lines, that
are separate in the input.
Reviewers: djasper
Reviewed By: djasper
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D2321
llvm-svn: 196378
Before:
int aaaa; // This line is formatted.
// The comment continues ..
// .. here.
Before:
int aaaa; // This line is formatted.
// The comment continues ..
// .. here.
This fixes llvm.org/PR17914.
llvm-svn: 195954
Previously, clang-format could create quite corrupt formattings if
individual lines of nested blocks (e.g. in "DEBUG({})" or lambdas) were
used. With this patch, it tries to extend the formatted regions to leave
around some reasonable format without always formatting the entire
surrounding statement.
llvm-svn: 195925
Summary:
getStringSplit used to crash, when trying to split a long string
literal containing both printable and unprintable multi-byte UTF-8 characters.
Reviewers: djasper, klimek
Reviewed By: djasper
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D2268
llvm-svn: 195728
No functional changes intended. However, it seems to have found a buggy
behavior in one of the tests. I think this structure is generally
desirable and it will make a planned bugfix significantly easier.
llvm-svn: 195634
Add a severe penalty for not using column layout for braced lists. If
there are solutions with column layout, these are generally preferable
over bin-packed solutions.
Before:
std::vector<MyValues> aaaaaaaaaaaaaaaaaaa{ aaaaaaa, aaaaaaaaaa, aaaaa,
aaaaaaaaaaaaaaa, aaa, aaaaaaaaaa, a,
aaaaaaaaaaaaaaaaaaaaa, aaaaaaaaaaaa,
aaaaaaaaaaaaaaaaaaa +
aaaaaaaaaaaaaaaaaaa,
aaaaaaa, a };
After:
std::vector<MyValues> aaaaaaaaaaaaaaaaaaa{
aaaaaaa, aaaaaaaaaa,
aaaaa, aaaaaaaaaaaaaaa,
aaa, aaaaaaaaaa,
a, aaaaaaaaaaaaaaaaaaaaa,
aaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaa + aaaaaaaaaaaaaaaaaaa,
aaaaaaa, a
};
llvm-svn: 195546
Summary:
Now based on token merging. Now they are not only prevented from being
split, but are actually formatted as comparison operators.
Reviewers: djasper, klimek
Reviewed By: klimek
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D2240
llvm-svn: 195354
In particular, make breaking after a parameter's ":" more of a last
resort choice as it significantly affects the readability gained by
aligning the parameters.
Before (in Chromium style - which doesn't allow bin-packing):
{
popup_window_.reset([[RenderWidgetPopupWindow alloc]
initWithContentRect:
NSMakeRect(
origin_global.x, origin_global.y, pos.width(), pos.height())
styleMask:NSBorderlessWindowMask
backing:NSBackingStoreBuffered
defer:NO]);
}
After:
{
popup_window_.reset([[RenderWidgetPopupWindow alloc]
initWithContentRect:NSMakeRect(origin_global.x,
origin_global.y,
pos.width(),
pos.height())
styleMask:NSBorderlessWindowMask
backing:NSBackingStoreBuffered
defer:NO]);
}
llvm-svn: 195301
Summary:
The AllowShortFunctionsOnASingleLine option now controls short function
body placement on a single line independent of the BreakBeforeBraces option.
Updated tests using BreakBeforeBraces other than BS_Attach.
Addresses http://llvm.org/PR17888
Reviewers: klimek, djasper
Reviewed By: klimek
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D2230
llvm-svn: 195256
Before, existing code in the form of:
int a; // this is a.
// This is
// b.
int b;
Got turned into:
int a; // this is a.
// This is
// b.
int b;
llvm-svn: 194294
Before:
unsigned ContentSize =
sizeof(int16_t) // DWARF ARange version number
+
sizeof(int32_t) // Offset of CU in the .debug_info section
+
sizeof(int8_t) // Pointer Size (in bytes)
+
sizeof(int8_t); // Segment Size (in bytes)
After:
unsigned ContentSize =
sizeof(int16_t) // DWARF ARange version number
+ sizeof(int32_t) // Offset of CU in the .debug_info section
+ sizeof(int8_t) // Pointer Size (in bytes)
+ sizeof(int8_t); // Segment Size (in bytes)
This fixes llvm.org/PR17687.
llvm-svn: 194276
As a side-effect, constructors definitions will correctly be recognized
and formatted as function declarations. Tests will be added in a
follow-up patch actually using the correct recognition.
llvm-svn: 194209
Before, clang-format would always format entire nested blocks, which
can be unwanted e.g. for long DEBUG({...}) statements. Also
clang-format would not allow to merge lines in nested blocks (e.g. to
put "if (a) return;" on one line in Google style).
This is the first step of several refactorings mostly focussing on the
additional functionality (by reusing the "format many lines" code to
format the children of a nested block). The next steps are:
* Pull out the line merging into its own class.
* Seperate the formatting of many lines from the formatting of a single
line (and the analysis of the solution space).
llvm-svn: 194090
Same as SpacesInParentheses, this option allows adding a space inside
the '<' and '>' of a template parameter list.
Patch by Christopher Olsen.
This fixes llvm.org/PR17301.
llvm-svn: 193614
Specifically make clang-format less eager to break after the opening
parenthesis of a function call.
Before:
aaaaaaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa + aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
After:
aaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa +
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
Apparently that is preferable. This penalties are adapted
conservatively, we might have to increase them a little bit further.
llvm-svn: 193410
This fixes llvm.org/PR17682.
Without this patch, the following code leads to invalid reads/writes:
DEBUG({
return aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa +
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa;
});
#if a
#else
#endif
Because of the #if-#else structure, the code is formatted and annotated
twice and becauce of the nested block, the annotated lines form a
hierarchical structure. This structure was not properly reset between
runs.
llvm-svn: 193352
Specifically, if a braced list has at least one nested braced list,
format it either all on one line or in one column (i.e. one item per
line).
This seems in general to be an improvement as the structure of nested
braced lists can make a tightly packed outer braced list hard to read.
llvm-svn: 193345
If we run into the second preprocessor branch chain, the first branch
chain might have already set the maximum branch count on that level to
something > 0.
Fixes PR17645.
llvm-svn: 193153
Now that we iterate on the formatting multiple times when we
have chains of preprocessor branches, we need to correctly reset
the token's previous and next pointer for the first / last token.
llvm-svn: 193071
Before:
DEBUG({ // Comment that used to confuse clang-format.
fdafas();
});
Before:
DEBUG({ // Comments are now fine.
fdafas();
});
This fixed llvm.org/PR17619.
llvm-svn: 193051
Before (note the missing space before "..." which can lead to compile
errors):
switch (x) {
case 'A'... 'Z':
case 1... 5:
break;
}
After:
switch (x) {
case 'A' ... 'Z':
case 1 ... 5:
break;
}
llvm-svn: 193050
Before, clang-format would not adjust leading indents if it found a
structural error (e.g. unmatched {}). It seems, however, that
clang-format has gotten good enough at parsing the code structure that
this hurts in almost all cases. Commonly, while writing code, it is
very useful to be able to correclty indent incomplete if statements or
for loops.
In case this leads to errors that we don't anticipate, we need to find
out and fix those.
This fixed llvm.org/PR17594.
llvm-svn: 192988
This looks ugly and leads to llvm.org/PR17590.
Before (with AlwaysBreakBeforeMultilineStrings):
return
"aaaa"
"bbbb";
After:
return "aaaa"
"bbbb";
llvm-svn: 192984
Specifically, prefer breaking before trailing annotations over breaking
before the first parameter.
Before:
void ffffffffffffffffffffffff(
int aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,
int aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa) OVERRIDE;
After:
void ffffffffffffffffffffffff(int aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,
int aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa)
OVERRIDE;
llvm-svn: 192983
Summary:
Store IndentationLevel in ParentState and use it instead of the
Line::Level when indening.
Also fixed incorrect indentation level calculation in formatFirstToken.
Reviewers: djasper
Reviewed By: djasper
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D1797
llvm-svn: 192563
While it is mostly a user error to have the extra semicolon,
formatting it graciously will correctly format in the cases
where we do not fully understand the code (macros).
llvm-svn: 192543
Summary:
This way we avoid breaking code which uses unknown preprocessor
directives with long string literals. The specific use case in
http://llvm.org/PR17035 isn't very common, but it seems to be a good idea to
avoid this kind of problem anyway.
Reviewers: djasper
Reviewed By: djasper
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D1813
llvm-svn: 192507
In certain macros or incorrect string literals, the token stream can
contain 'unknown' tokens, e.g. a single backslash or a set of empty
ticks. clang-format simply treated them as whitespace and removed them
prior to this patch.
This fixes llvm.org/PR17215
llvm-svn: 192490
Before, clang-format would always insert a linebreak before the comment
in code like:
template <typename T> // T can be A, B or C.
struct S {};
llvm-svn: 192297
Specifically make ConstructorInitializerAllOnOneLineOrOnePerLine work
nicely with BreakConstructorInitializersBeforeComma.
This fixes llvm.org/PR17395.
llvm-svn: 192168
Previously, comments, could totally confuse it.
Before:
return
// true if code is one of a or b.
code == a ||
code == b;
After:
return
// true if code is one of a or b.
code == a || code == b;
llvm-svn: 191654
Summary:
Changed UseTab to be a enum with three options: Never, Always,
ForIndentation (true/false are still supported when reading .clang-format).
IndentLevel should currently be propagated correctly for all tokens, except for
block comments. Please take a look at the general idea before I start dealing
with block comments.
Reviewers: klimek, djasper
Reviewed By: klimek
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1770
llvm-svn: 191527
Summary:
The width of the first inserted tab character depends on the initial
column, so we need to handle the first tab in a special manner.
Reviewers: klimek, djasper
Reviewed By: klimek
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1763
llvm-svn: 191497
Before:
template <typename T>
// T should be one of {A, B}.
void f() {}
After:
template <typename T>
// T should be one of {A, B}.
void f() {}
llvm-svn: 191492
Before (with column limit 60):
aaaaaaaaaaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaaaaaaaa >
> aaaaa);
After:
aaaaaaaaaaaaaaaaaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaaaaaaaaaaa >> aaaaa);
(Not sure how that could have stayed in that long without being
detected..)
llvm-svn: 190854
Before:
template <template <typename>
class Fooooooo, template <typename>
class Baaaaaaar>
struct C {};
After:
template <template <typename> class Fooooooo,
template <typename> class Baaaaaaar>
struct C {};
llvm-svn: 190747
Summary:
reformat() tries to determine the newline style used in the input
(either LF or CR LF), and uses it for the output. Maybe not every single case is
supported, but at least the bug described in http://llvm.org/PR17182 should be
resolved.
Reviewers: djasper
Reviewed By: djasper
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D1643
llvm-svn: 190519
Summary: This also unifies the handling of escaped newlines for all tokens.
Reviewers: djasper
Reviewed By: djasper
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D1638
llvm-svn: 190405
Summary:
This fixes various issues with mixed tabs and spaces handling, e.g.
when realigning block comments.
Reviewers: klimek, djasper
Reviewed By: djasper
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1608
llvm-svn: 190395
Let clang-format consistently keep up to one empty line (configured via
FormatStyle::MaxEmptyLinesToKeep) in nested blocks, e.g. lambdas. Also,
actually format single statements in nested blocks.
Before:
DEBUG({ int i; });
DEBUG({
int i;
// an empty line here would just be removed.
int j;
});
After:
DEBUG({ int i; });
DEBUG({
int i;
int j;
});
llvm-svn: 190278
Before:
FirstToken->WhitespaceRange.getBegin()
.getLocWithOffset(First->LastNewlineOffset);
After:
FirstToken->WhitespaceRange.getBegin().getLocWithOffset(
First->LastNewlineOffset);
Re-add logic to prevent breaking after an empty set of parentheses.
Basically it seems that calling a function without parameters is more
like navigating along the same object than it is a separate step of a
builder-type call.
We might need to extends this in future to allow "short" parameters that
e.g. are an index accessing a specific element.
llvm-svn: 190126
This fixes two issues:
1) The indent of a line comment was not adapted to the subsequent
statement as it would be outside of a nested block.
2) A missing DryRun flag caused actualy breaks to be inserted in
overly long comments while trying to come up with the best line
breaking decisions.
llvm-svn: 190123
Summary:
Count column width instead of the number of code points. This also
includes correct handling of tabs inside string literals and comments (with an
exception of multiline string literals/comments, where tabs are present before
the first escaped newline).
Reviewers: djasper, klimek
Reviewed By: klimek
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D1601
llvm-svn: 190052
This patch makes sure we produce the right number of unwrapped lines,
a follow-up patch will make the whitespace formatting consistent.
Before:
void f() {
int i = {[operation setCompletionBlock : ^{ [self onOperationDone];
}]
}
;
}
After:
void f() {
int i = {[operation setCompletionBlock : ^{
[self onOperationDone];
}] };
}
llvm-svn: 189932
Implements parsing of lambdas in the UnwrappedLineParser.
This introduces the correct line breaks; the formatting of
lambda captures are still incorrect, and the braces are also
still formatted as if they were braced init lists instead of
blocks.
llvm-svn: 189818
Almost by accident, clang-format seems to be able to format protocol
buffer definitions (https://code.google.com/p/protobuf/).
The only change is that a space is required between numeric constants
and opening square brackets (for default values). While this might in
theory be used for array subscripts (int val = 4[MyArray]), I have not
seen this pattern in practice much. If this is wrong, we can make this
smarter in the future.
llvm-svn: 189663
Before:
aaaaaaaaaa(bbbbbbbbbbbbbbbbbbbbbbbbb.ccccccccccccccccc(
dddddddddddddddddddddddddddddd));
aaaaaaaaaaa(bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb(
dddddddddddddddddddddddddddddd));
After:
aaaaaaaaaaa(bbbbbbbbbbbbbbbbbbbbbbbbb.ccccccccccccccccc(
dddddddddddddddddddddddddddddd));
aaaaaaaaaaa(bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb(
dddddddddddddddddddddddddddddd));
This was overlooked when interducing the new builder-type call
detection in r189337. Also, some minor reorganization of a test.
llvm-svn: 189658
While this looks kind of nice, it wastes horizontal space and does not
seem to be common in the LLVM codebase.
Before:
return llvm::StringSwitch<Reference::Kind>(name)
.StartsWith(".eh_frame_hdr", ORDER_EH_FRAMEHDR)
.StartsWith(".eh_frame", ORDER_EH_FRAME)
.StartsWith(".init", ORDER_INIT)
.StartsWith(".fini", ORDER_FINI)
.StartsWith(".hash", ORDER_HASH)
.Default(ORDER_TEXT);
After:
return llvm::StringSwitch<Reference::Kind>(name)
.StartsWith(".eh_frame_hdr", ORDER_EH_FRAMEHDR)
.StartsWith(".eh_frame", ORDER_EH_FRAME)
.StartsWith(".init", ORDER_INIT)
.StartsWith(".fini", ORDER_FINI)
.StartsWith(".hash", ORDER_HASH)
.Default(ORDER_TEXT);
llvm-svn: 189657
Summary:
Calculate characters in the first and the last line correctly so that
we only break before the literal when needed.
Reviewers: djasper
Reviewed By: djasper
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D1544
llvm-svn: 189595
We now count the original token's column directly when lexing the
tokens, where we already have all knowledge about where lines start.
Before this patch, formatting:
void f() {
\tg();
\th();
}
would incorrectly count the \t's as 1 character if only the line
containing h() was reformatted, and thus indent h() at offset 1.
llvm-svn: 189585
Two changes:
* Don't add an extra penalty on breaking the same token multiple times.
Generally, we should prefer not to break, but once we break, the
normal line breaking penalties apply.
* Slightly increase the penalty for breaking comments. In general, the
author has put some thought into how to break the comment and we
should not overwrite this unnecessarily.
With a 40-column column limit, formatting
aaaaaa("aaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaa");
Leads to:
Before:
aaaaaa(
"aaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaa "
"aaaaaaaaaaaaaaaa");
After:
aaaaaa("aaaaaaaaaaaaaaaa "
"aaaaaaaaaaaaaaaa "
"aaaaaaaaaaaaaaaa");
llvm-svn: 189466
The code leading to a segfault was:
#pragma omp threadprivate(y)), // long comment leading to a line break
This fixes llvm.org/PR16513.
llvm-svn: 189460
If escaped newlines are aligned right
(FormatStyle.AlignEscapedNewlinesLeft == false), and a line contained
too many characters to fit into the column limit, this would result in
a (virtually) endless loop creating a negative number of spaces.
Instead, allow the escaped newlines to be pushed past the column limit
in this case.
This fixes llvm.org/PR16515.
llvm-svn: 189459
In
@implementation ObjcClass
- (void)method;
{
}
@end
the ObjC compiler seems to accept the superfluous comma after "method",
but clang-format used to assert on the subsequent "{".
This fixes llvm.org/PR16604.
llvm-svn: 189453
Specific arrangements of comments after trailing commas could confuse
the column width calculation, e.g. in:
vector<int> x = { a, b,
/* some */ /* comment */ };
llvm-svn: 189211
This should be done, only if we are still in the unary expression's
scope.
Before:
bool aaaa = !aaaaaaaa( // break
aaaaaaaaaaa);
*aaaaaa = aaaaaaa( // break
aaaaaaaaaaaaaaaa);
After:
bool aaaa = !aaaaaaaa( // break
aaaaaaaaaaa); // <- (unchanged)
*aaaaaa = aaaaaaa( // break
aaaaaaaaaaaaaaaa); // <- (no longer indented relative to "*")
llvm-svn: 189108
.. in conjunction with Style.AlwaysBreakBeforeMultilineStrings. Also,
simplify the implementation by handling newly split strings and already
split strings by the same code.
llvm-svn: 189102
Before, this was causing errors.
Also exit early in breakProtrudingToken() (before the expensive call to
SourceManager::getSpellingColumnNumber()). This makes formatting huge
(100k+-item) braced lists possible.
llvm-svn: 189094
With this patch, braced lists (with more than 3 elements are formatted in a
column layout if possible). E.g.:
static const uint16_t CallerSavedRegs64Bit[] = {
X86::RAX, X86::RDX, X86::RCX, X86::RSI, X86::RDI,
X86::R8, X86::R9, X86::R10, X86::R11, 0
};
Required other changes:
- FormatTokens can now have a special role that contains extra data and can do
special formattings. A comma separated list is currently the only
implementation.
- Move penalty calculation entirely into ContinuationIndenter (there was a last
piece still in UnwrappedLineFormatter).
Review: http://llvm-reviews.chandlerc.com/D1457
llvm-svn: 189018
Before:
if (!aaaaaaaaaa( // break
aaaaa)) {
}
After:
if (!aaaaaaaaaa( // break
aaaaa)) {
}
Also cleaned up formatting using clang-format.
llvm-svn: 188891
This patch adds four new options to control:
- Spaces after control keyworks (if(..) vs if (..))
- Spaces in empty parentheses (f( ) vs f())
- Spaces in c-style casts (( int )1.0 vs (int)1.0)
- Spaces in other parentheses (f(a) vs f( a ))
Patch by Joe Hermaszewski. Thank you for working on this!
llvm-svn: 188793
Some coding styles use a different indent for constructor initializers.
Patch by Klemens Baum. Thank you.
Review: http://llvm-reviews.chandlerc.com/D1360
Post review changes: Changed data type to unsigned as a negative indent
width does not make sense and added test for configuration parsing.
llvm-svn: 188260
Previously these were formatting as catch (E & e) because the inner parenthesis
was being marked as an expression.
Patch by Thomas Gibson-Robinson.
llvm-svn: 188153
In particular, left braces after an enum declaration now occur on their
own line. Further, when short ifs/whiles are allowed these no longer
cause the left brace to be on the same line as the if/while when a
brace is included.
Patch by Thomas Gibson-Robinson.
llvm-svn: 187901
This removes a formatting choice that was added at one point, but is
not generally liked by users. Specifically, in builder-type calls, do
(easily) break if the object before the ./-> is either a field or a
parameter-less function call. I.e., don't break after "aa.aa.aa" or
"aa.aa.aa()". In general, these sequences in builder-type calls are
seen as a single entity and thus breaking them up is a bad idea.
llvm-svn: 187865
Before, clang-format would not break overly long string literals
following a "<<" with FormatStyle::AlwaysBreakBeforeMultilineStrings
being set.
llvm-svn: 187650
Before:
template <bool B, bool C>
class A {
static_assert(B &&C, "Something is wrong");
};
After:
template <bool B, bool C>
class A {
static_assert(B && C, "Something is wrong");
};
(Note the spacing around '&&'). Also change the identifier table to always
understand all C++11 keywords (which seems like the right thing to do).
llvm-svn: 187589
With this patch, clang-format can be configured to:
* not indent in namespace at all (former behavior).
* indent in namespace as in other blocks.
* indent only in inner namespaces (as required by WebKit style).
Also fix alignment of access specifiers in WebKit style.
Patch started by Marek Kurdej. Thank you!
llvm-svn: 187540
New options:
* Break before the commas of constructor initializers and align
the commas with the colon.
* Break before binary operators
Additionally, for styles without column limit, don't just accept
linebreaks done by the user, but instead remove 'invalid' (according
to the current style) linebreaks and add 'required' ones.
llvm-svn: 187210
This is far from implementing all the rules given by
http://www.webkit.org/coding/coding-style.html
The important new feature is the support for styles that don't have a
column limit. For such styles, clang-format will (at the moment) simply
respect the input's formatting decisions within statements.
llvm-svn: 187033
The AlwaysBreakBeforeMultilineStrings rule does not really make sense
if it does not a column gain.
Before (in Google style):
f(
"aaaa"
"bbbb");
After:
f("aaaa"
"bbbb");
llvm-svn: 186515
Motivating example:
// column limit ------------------->
void ffffffffffff(int aaaaaa /* test */);
Formatting before the patch:
void ffffffffffff(int aaaaaa /* test
*/);
Formatting after the patch:
void
ffffffffffff(int aaaaaa /* test */);
llvm-svn: 186471
Summary:
These can appear when comments contain command lines with quoted line
breaks. As the text (including escaped newlines and '//' from consecutive lines)
is a single line comment, we used to break it even when it didn't exceed column
limit. This is a temporary solution, in the future we may want to support this
case completely - at least adjust leading whitespace when changing indentation
of the first line.
Reviewers: djasper
Reviewed By: djasper
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D1146
llvm-svn: 186456
The fundamental concept is:
Format as if the braced init list was a function call (with parentheses
replaced by braces). If there is no name/type before the opening brace
(e.g. if the braced list is nested), assume a zero-length identifier
just before the opening brace.
This behavior is gated on a new style flag, which for now replaces the
SpacesInBracedLists style flag. Activate this style flag for Google
style to reflect recent style guide changes.
llvm-svn: 186433
This fixes an incorrect detection that led to a formatting error.
Before:
some_var = function (*some_pointer_var)[0];
After:
some_var = function(*some_pointer_var)[0];
llvm-svn: 186402
Fixed a test that by now passed for the wrong reason.
Before:
llvm::outs() << "aaaaaaaaaaaaaaaaaaa: " << aaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaaaaaaaaaa);
After:
llvm::outs() << "aaaaaaaaaaaaaaaaaaa: "
<< aaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaaaaaaa);
Also reformatted Format.cpp with the latest changes (1 formatting fix
and 1 layout change of a <<-chain).
llvm-svn: 186322
Before this patch, it did not cooperate with
Style::AlwaysBreakBeforeMultilineStrings. Thus, it would turn
aaaaaaaaaaaa(aaaaaaaaaaaaa, "aaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaa");
into:
aaaaaaaaaaaa(aaaaaaaaaaaaa, "aaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaa "
"aaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaa");
and only a second format step would lead to the desired (with that
option):
aaaaaaaaaaaa(aaaaaaaaaaaaa,
"aaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaa "
"aaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaa");
This could even lead to clang-format breaking the string at a different
character and thus leading to a completely different end result.
llvm-svn: 186154
clang-format used to treat array subscript expressions much like
function call (just replacing () with []). However, this is not really
appropriate especially for expressions with multiple subscripts.
Although it might seem counter-intuitive, the most consistent solution
seems to be to always (if necessary) break before a square bracket,
never after it. Also, multiple subscripts of the same expression should
be aligned if they are on subsequent lines.
Before:
aaaaaaaaaaaaaaaaaaaaaaaaa[aaaaaaaaaaaaaaaaaaaaaaaaa][
bbbbbbbbbbbbbbbbbbbbbbbbb] = c;
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa[
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa][
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb] = ccccccccccc;
After:
aaaaaaaaaaaaaaaaaaaaaaaaa[aaaaaaaaaaaaaaaaaaaaaaaaa]
[bbbbbbbbbbbbbbbbbbbbbbbbb] = c;
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
[aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa]
[bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb] = ccccccccccc;
llvm-svn: 186153
Before:
int i; // indented 2 space more than clang-format would use.
SomeReturnType // clang-format invoked on this line.
SomeFunctionMakingLBraceEndInColumn80() {
} // This is the indent clang-format would prefer.
After:
int i; // indented 2 space more than clang-format would use.
SomeReturnType // clang-format invoked on this line.
SomeFunctionMakingLBraceEndInColumn80() {
}
llvm-svn: 186120
(if they are not function-like).
Before:
SomeFunction(aaaaaaaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaaaaaa)
OVERRIDE;
After:
SomeFunction(aaaaaaaaaaaaaaaaaaaaaa,
aaaaaaaaaaaaaaaaaaaaaaaa) OVERRIDE;
llvm-svn: 186117
This puts a slight penalty on the linebreak before the first "<<", so
that clang-format generally tries to keep things on the first line.
User feedback has shown that this is generally desirable.
Before:
llvm::outs()
<< "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa =" << aaaaaaaaaaaaaaaaaaaaaaaaaaa;
After:
llvm::outs() << "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ="
<< aaaaaaaaaaaaaaaaaaaaaaaaaaa;
llvm-svn: 186115
Trailing return types can only occur in declaration contexts.
Before:
void f() { auto a = b -> c(); }
After:
void f() { auto a = b->c(); }
llvm-svn: 186087
This is not activated for any style, might change or go away
completely.
For those that want to play around with it, set
ExperimentalAutoDetectBinPacking to true.
clang-format will then:
Look at whether function calls/declarations/definitions are currently
formatted with one parameter per line (on a case-by-case basis). If so,
clang-format will avoid bin-packing the parameters. If all parameters
are on one line (thus that line is "inconclusive"), clang-format will
make the choice dependent on whether there are other bin-packed
calls/declarations in the same file.
The reason for this change is that bin-packing in some situations can be
really bad and an author might opt to put one parameter on each line. If
the author does that, he might want clang-format not to mess with that.
If the author is unhappy with the one-per-line formatting, clang-format
can easily be convinced to bin-pack by putting any two parameters on the
same line.
llvm-svn: 186003
This fixes llvm.org/PR15170.
For now, the basic formatting rules are (based on the C++11 standard):
* Surround the "->" with spaces.
* Break before "->".
Also fix typo.
llvm-svn: 185938
Basically treat a function with a trailing call similar to a function
with multiple parameters.
Before:
aaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaa))
.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa();
After:
aaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaa))
.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa();
Also fix typo.
llvm-svn: 185930
Before:
someFunction(OtherParam, BracedList{
// comment 1 (Forcing intersting break)
param1, param2,
// comment 2
param3, param4
});
After:
someFunction(OtherParam, BracedList{
// comment 1 (Forcing intersting break)
param1, param2,
// comment 2
param3, param4
});
To do so, the UnwrappedLineParser now stores the information about the
kind of brace in the FormatToken.
llvm-svn: 185914
Daniel Jasper