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 makes ContinuationIndenter call breakProtrudingToken only if
NoLineBreak and NoLineBreakInOperand is false.
Previously, clang-format required two runs to converge on the following example with 24 columns:
Note that the second operand shouldn't be splitted according to NoLineBreakInOperand, but the
token breaker doesn't take that into account:
```
func(a, "long long long long", c);
```
After first run:
```
func(a, "long long "
"long long",
c);
```
After second run, where NoLineBreakInOperand is taken into account:
```
func(a,
"long long "
"long long",
c);
```
With the patch, clang-format now obtains in one run:
```
func(a,
"long long long"
"long",
c);
```
which is a better token split overall.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D30575
llvm-svn: 297274
Summary:
This patch enables comment reflowing of lines not matching the comment pragma regex
in multiline comments containing comment pragma lines. Previously, these comments
were dumped without being reindented to the result.
Reviewers: djasper, mprobst
Reviewed By: mprobst
Subscribers: klimek, mprobst, cfe-commits
Differential Revision: https://reviews.llvm.org/D30697
llvm-svn: 297261
r289428 added a separate language kind for Objective-C, but kept many
"Language == LK_Cpp" checks untouched. This introduced a "IsCpp()"
method that returns true for both C++ and Objective-C++, and replaces
all comparisons of Language with LK_Cpp with calls to this new method.
Also add a lot more test coverge for formatting things in LK_ObjC mode,
by having FormatTest's verifyFormat() test for LK_ObjC everything that's
being tested for LK_Cpp at the moment.
Fixes PR32060 and many other things.
llvm-svn: 296160
Specifically, similar to other blocks, clang-format now wraps both
after "${" and before the corresponding "}", if the contained
expression spans multiple lines.
llvm-svn: 295663
Summary:
The comment reflower wasn't taking comment pragmas as reflow stoppers. This patch fixes that.
source:
```
// long long long long
// IWYU pragma:
```
format with column limit = 20 before:
```
// long long long
// long IWYU pragma:
```
format with column limit = 20 after:
```
// long long long
// long
// IWYU pragma:
```
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D29450
llvm-svn: 293898
Without alignment, there is no clean separation between the arguments, even if
there are only two.
Before:
aaaaaaaaaaaaaa(
aaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa +
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
After:
aaaaaaaaaaaaaa(aaaaaaaaaaaa,
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa +
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
llvm-svn: 293875
This rows back on r288120, r291801 and r292110. I apologize in advance
for the churn. All of those revisions where meant to make the wrapping
of RHS expressions more consistent. However, now that they are
consistent, we seem to be a bit too eager.
The reasoning here is that I think it is generally correct that we want
to line-wrap before multiline RHS expressions (or multiline arguments to
a function call). However, if there are only two of such operands or
arguments, there is always a clear vertical separation between them and
the additional line break seems much less desirable.
Somewhat good examples are expressions like:
EXPECT_EQ(2, someLongExpression(
orCall));
llvm-svn: 293752
This only affects expressions inside ${} scopes of template strings.
Here, we want to indent relative to the surrounding template string and
not the surrounding expression. Otherwise, this can create quite a mess.
Before:
var f = `
aaaaaaaaaaaaaaaaaa: ${someFunction(
aaaaa + //
bbbb)}`;
After:
var f = `
aaaaaaaaaaaaaaaaaa: ${someFunction(
aaaaa + //
bbbb)}`;
llvm-svn: 293636
The main motivation behind this is to cleanup the WhitespaceManager and
make it more extensible for future alignment etc. features.
Specifically, WhitespaceManager has started to copy more and more code
that is already present in FormatToken. Instead, I think it makes more
sense to actually store a reference to each FormatToken for each change.
This has as a consequence led to a change in the calculation of indent
levels. Now, we actually compute them for each Token ahead of time,
which should be more efficient as it removes an unsigned value for the
ParenState, which is used during the combinatorial exploration of the
solution space.
No functional changes intended.
Review: https://reviews.llvm.org/D29300
llvm-svn: 293616
This had significant negative consequences and I don't have a good
solution for it yet.
Before:
var string =
[
'aaaaaa',
'bbbbbb',
]
.join('+');
After:
var string = [
'aaaaaa',
'bbbbbb',
].join('+');
llvm-svn: 293465
Summary:
This presents a version of the comment reflowing with less mutable state inside
the comment breakable token subclasses. The state has been pushed into the
driving breakProtrudingToken method. For this, the API of BreakableToken is enriched
by the methods getSplitBefore and getLineLengthAfterSplitBefore.
Reviewers: klimek
Reviewed By: klimek
Subscribers: djasper, klimek, mgorny, cfe-commits, ioeric
Differential Revision: https://reviews.llvm.org/D28764
llvm-svn: 293055
Before:
aaaaaaaaaaaaaaaaaa(aaaaaaaa, aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa::
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,
aaaaaaaaaaaaaaaaaaaaa);
After:
aaaaaaaaaaaaaaaaaa(aaaaaaaa,
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa::
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,
aaaaaaaaaaaaaaaaaaaaa);
No new test cases, as the existing ones cover this fairly well.
llvm-svn: 292110
Here, the optimization to not line wrap when it would not lead to a
reduction in columns was overwriting and enforced break that we want to
do no matter what.
Before:
int i = someFunction(
aaaaaaa,
0).aaa(aaaaaaaaaaaaa) *
aaaaaaa +
aaaaaaa;
After:
int i = someFunction(aaaaaaa, 0)
.aaa(aaaaaaaaaaaaa) *
aaaaaaa +
aaaaaaa;
llvm-svn: 291974
Specifically, wrap before them if they are multi-line so that we don't
create long hanging indents. This prevents having a lot of code
indented a lot in some cases.
Before:
someFunction(Param, {List1, List2,
List3});
After:
someFunction(Param,
{List1, List2,
List3});
llvm-svn: 291801
Before:
SomeLongLoggingStatementOrMacro() << "Some long text "
<< some_variable << "\n";
Before:
SomeLongLoggingStatementOrMacro()
<< "Some long text " << some_variable << "\n";
Short logging statements are already special cased in a different part
of the code.
llvm-svn: 290094
While C(++) and ObjC are generally formatted the same way and can be
mixed, people might want to choose different styles based on the
language. This patch recognizes .m and .mm files as ObjC and also
implements a very crude detection of whether or not a .h file contains
ObjC code. This can be improved over time.
Also move most of the ObjC tests into their own test file to keep file
size maintainable.
llvm-svn: 289428
Specifically, if the RHS of a comma is a complex binary expression and
spans multiple lines, insert a line break before it. This usually is
often more readable compared to producing a hanging indent. See changes
in FormatTest.cpp for examples.
llvm-svn: 288120
If a call takes a single argument, using AlwaysBreak can lead to lots
of wasted lines and additional indentation without improving the
readability in a significant way.
Before:
caaaaaaaaaaaall(
caaaaaaaaaaaall(
caaaaaaaaaaaall(
caaaaaaaaaaaaaaaaaaaaaaall(aaaaaaaaaaaaaa, aaaaaaaaa))));
After:
caaaaaaaaaaaall(caaaaaaaaaaaall(caaaaaaaaaaaall(
caaaaaaaaaaaaaaaaaaaaaaall(aaaaaaaaaaaaaa, aaaaaaaaa))));
llvm-svn: 263709
Before:
int i = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ?
/*bbbbbbbbbbbbbbbbbbbb=*/bbbbbbbbbbbbbbbbbbbbbbbbb :
ccccccccccccccccccccccccccc;
After:
int i = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ?
/*bbbbbbbbbbbbbbbbbbbb=*/bbbbbbbbbbbbbbbbbbbbbbbbb :
ccccccccccccccccccccccccccc;
llvm-svn: 259670
After reading the style guides again, they don't actually say how to
pack or not pack array literals. Based on some user reports, array
initializers can unnecessarily get quite long if they contain many
small elements. Array literals with trailing commas are still formatted
one per line so that users have a way to opt out of the packing.
Before:
var array = [
aaaaaa,
aaaaaa,
aaaaaa,
aaaaaa,
aaaaaa,
aaaaaa,
aaaaaa,
aaaaaa,
aaaaaa,
aaaaaa
];
After:
var array = [
aaaaaa, aaaaaa, aaaaaa, aaaaaa, aaaaaa, aaaaaa, aaaaaa, aaaaaa, aaaaaa,
aaaaaa, aaaaaa
];
llvm-svn: 257615
r257257 change the way clang-format enforces line breaks after a
templated type has been line-wrapped. This was to fix an incorrect line
break if BinPackParameters is set to false. However, it also leads to
an unwanted line break in a different case. Thus, for now, only do this
when BinPackParameters is false. This isn't ideal yet, but helps us
until we have a better solution.
With BinPackParameters:
Before:
void fffffffffff(aaaaaaaaaaaaaaaaaaaaaaaaaaa<aaaaaaaaaaaaaaaaaaaaaaa,
aaaaaaaaaa> aaaaaaaaaa);
After:
void fffffffffff(
aaaaaaaaaaaaaaaaaaaaaaaaaaa<aaaaaaaaaaaaaaaaaaaaaaa, aaaaaaaaaa>
aaaaaaaaaa);
llvm-svn: 257325
Before (example is JS, but also applies to C++):
return [
aaaa()
.bbbbbbbb('A'),
aaaa().bbbbbbbb('B'),
aaaa().bbbbbbbb('C'),
];
After:
return [
aaaa().bbbbbbbb('A'),
aaaa().bbbbbbbb('B'),
aaaa().bbbbbbbb('C'),
];
llvm-svn: 257079
r256750 has been leading to an undesired behavior:
aaaaaaaaaa
.aaaaaaaaaaaaaaaaaaaaaaaa.aaaaaa(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
This change increases penalty for wrapping before member accesses that aren't
calls. Thus, this is again formatted as (as it has been before r256750):
aaaaaaaaaa.aaaaaaaaaaaaaaaaaaaaaaaa.aaaaaa(
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
llvm-svn: 256830
This changes the behavior of AlwaysBreakAfterDeclarationReturnType
so that it supports breaking after declarations, definitions, or
both.
Differential Revision: http://reviews.llvm.org/D10370
Reviewed By: Daniel Jasper
llvm-svn: 256046
Specifically, don't wrap between the {} of an empty constructor if the
"}" falls on column 81 and ConstructorInitializerAllOnOneLineOrOnePerLine
is set.
llvm-svn: 251406
Summary:
If this option is set, clang-format will always insert a line wrap, e.g.
before the first parameter of a function call unless all parameters fit
on the same line. This obviates the need to make a decision on the
alignment itself.
Use this style for Google's JavaScript style and add some minor tweaks
to correctly handle nested blocks etc. with it. Don't use this option
for for/while loops.
Reviewers: klimek
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D14104
llvm-svn: 251405
This is a bit of a step back of what we did in r222531, as there are
some corner cases in C++, where this kind of formatting is really bad.
Example:
Before:
virtual aaaaaaaaaaaaaaaa(std::function<bool()> IsKindWeWant = [&]() {
return true;
}, aaaaa aaaaaaaaa);
After:
virtual aaaaaaaaaaaaaaaa(std::function<bool()> IsKindWeWant =
[&]() { return true; },
aaaaa aaaaaaaaa);
The block formatting logic in JavaScript will probably go some other changes,
too, and we'll potentially be able to make the rules more consistent again. For
now, this seems to be the best approach for C++.
llvm-svn: 245694
conservative.
In particular, this fixes an unwanted corner case.
Before:
string s =
someFunction("aaaa"
"bbbb");
After:
string s = someFunction(
"aaaa"
"bbbb");
llvm-svn: 240129
It was a bit too aggressive.
With this patch, we keep on breaking here:
aaaaaaaaaaaaa(aaaaaaa,
"aaaaaaa"
"bbbbbbb");
But don't break in:
aaaaaaaaaaaaa(aaaaaaa, aaaaaaaa("aaaaaaa"
"bbbbbbb"));
llvm-svn: 240024
Before:
var func =
function() {
doSomething();
};
After:
var func =
function() {
doSomething();
};
This is a very narrow special case which fixes most of the discrepency
with what our users do. In the long run, we should try to come up with
a more generic fix for indenting these.
llvm-svn: 240014
In essence this is meant to consistently indent multiline strings by a
fixed amount of spaces from the start of the line. Don't do this in
cases where it wouldn't help anyway.
Before:
someFunction(aaaaa,
"aaaaa"
"bbbbb");
After:
someFunction(aaaaa, "aaaaa"
"bbbbb");
llvm-svn: 240004
Before:
template <typename T>
auto aaaaaaaaaaaaaaaaaaaaaa(T t) -> decltype(eaaaaaaaaaaaaaaa<T>(t.a)
.aaaaaaaa());
After:
template <typename T>
auto aaaaaaaaaaaaaaaaaaaaaa(T t)
-> decltype(eaaaaaaaaaaaaaaa<T>(t.a).aaaaaaaa());
Also add a test case for a difficult template parsing case I stumbled accross.
Needs fixing.
llvm-svn: 239149
Before:
someFunction(() =>
{
doSomething(); // break
})
.doSomethingElse( // break
);
After:
someFunction(() => {
doSomething(); // break
})
.doSomethingElse( // break
);
This is still bad, but at least it is consistent with what we do for other
function literals. Added corresponding tests.
llvm-svn: 238736
A definintion like this could not be formatted at all:
constructor({aa}: {
aa?: string,
aaaaaaaa?: string,
aaaaaaaaaaaaaaa?: boolean,
aaaaaa?: List<string>
}) {
}
llvm-svn: 238291
instead of BinPackParameters. Braced lists are used as constructor
calls in many places and so the bin-packing should follow what is done
for other calls and not what is done for function declarations.
llvm-svn: 238184
Before:
ASSERT("aaaaaaaaaaaaaaa")
<< aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
<< bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb;
After:
ASSERT("aaaaaaaaaaaaaaa") << aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
<< bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb;
Also cleanup implementation a bit and only mark closing parenthesis of
these annotations.
llvm-svn: 237567
before binary/ternary operators.
Basically, it doesn't seem right to indent a nested block aligned to a
binary or ternary operator.
Before:
int i = aaaaaa ? 1 //
: [] {
return 2; //
}();
llvm::errs() << "number of twos is "
<< std::count_if(v.begin(), v.end(), [](int x) {
return x == 2; // force break
});
After:
int i = aaaaaa ? 1 //
: [] {
return 2; //
}();
llvm::errs() << "number of twos is "
<< std::count_if(v.begin(), v.end(), [](int x) {
return x == 2; // force break
});
llvm-svn: 237263
Before:
[aaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaa:
aaaaaaaa aaa:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa];
After:
[aaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaa:aaaaaaaa
aaa:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa];
Note that this might now violate the column limit and we probably need an
alternative way of indenting these then. However, that is still strictly better
than the messy formatting that clang-format did before.
llvm-svn: 236598
There was already a TODO to double-check whether the extra indenation
makes sense. A slightly different case reveals that it is actively harmful:
for (int i = 0; i < aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ||
bbbbbbbbbbbbbbbbbbbb < ccccccccccccccc;
++i) {
}
Here (and it is probably not a totally infrequent case, it just works out that
"i < " is four spaces and so the four space extra indentation makes the
operator precedence confusing. So, this will now instead be formatted
as:
for (int i = 0; i < aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ||
bbbbbbbbbbbbbbbbbbbb < ccccccccccccccc;
++i) {
}
llvm-svn: 231461
Before:
Aaaa aaaaaaaaaaa{
{
a, // +1 indent weird.
b, // trailing comma signals one per line.
}, // trailing comma signals one per line.
};
After:
Aaaa aaaaaaaaaaa{
{
a, // better!?
b, // trailing comma signals one per line.
}, // trailing comma signals one per line.
};
Interesting that this apparently was entirely untested :-(.
llvm-svn: 230627
The proper way to break string literals in these languages is by inserting a "+"
between parts which we don't support yet. So we disable string literal breaking
until then.
llvm-svn: 224120
This only applies when not aligning after the return itself (which is
commonly done for C++.
Before:
return aaaaaaaaaa
? bbbbbbbbbb(
bbbbbb) // This is indented relative to aaaaaaaaaa.
: b;
After:
return aaaaaaaaaa
? bbbbbbbbbb(
bbbbbb)
: b;
llvm-svn: 223694
With alignment:
int aaaaaa = aa
+ bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
* cccccccccccccccccccccccccccccccc;
Without alignment:
int aaaaaa = aa
+ bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
* cccccccccccccccccccccccccccccccc;
This fixes llvm.org/PR21666.
llvm-svn: 223117
Previously this was only used for JavaScript.
Before:
functionCall({
int i;
int j;
},
aaaa, bbbb, cccc);
After:
functionCall({
int i;
int j;
}, aaaa, bbbb, cccc);
llvm-svn: 222531
Doesn't seem to be common practice in Java.
Before:
return aaaaaaaaaaaaaaaaaaa
&& bbbbbbbbbbbbbbbbbbb
&& ccccccccccccccccccc;
After:
return aaaaaaaaaaaaaaaaaaa
&& bbbbbbbbbbbbbbbbbbb
&& ccccccccccccccccccc;
Patch by Harry Terkelsen.
llvm-svn: 222424
Apparently, people are very much divided on what the "correct"
indentation is. So, best to give them a choice.
The new flag is called ObjCBlockIndentWidth and the default is now set
to the same value as IndentWidth for the pre-defined styles.
llvm-svn: 220784
Before:
void
SomeFunction(int parameter);
After:
void SomeFunction(
int parameter);
(Unless AlwaysBreakAfterDefinitionReturnType after type is set).
llvm-svn: 220686
Before:
auto aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa =
new (aaaaaaaaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaa))
typename aaaaaaaaaaaaaaaaaaaaaaaa();
After:
auto aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa =
new (aaaaaaaaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaa))
typename aaaaaaaaaaaaaaaaaaaaaaaa();
llvm-svn: 214964
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
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
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
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
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
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
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
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
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
- 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
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
Daniel Jasper