| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
The more general code for formatting ObjC method exprs does this and more,
it's no longer necessary to special-case this. No behavior change.
llvm-svn: 174843
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
@{
foo:
bar
}
;
Now:
@{ foo : bar };
parseBracedList() already does the right thing from an UnwrappedLineParser
perspective, so check for "@{" in all loops that process constructs that can
contain expressions and call parseBracedList() if found.
llvm-svn: 174840
|
|
|
|
| |
llvm-svn: 174823
|
|
|
|
|
|
|
|
| |
Use this to add a space after "@[" and before "]" for now.
Later, I want to use this to format multi-line array literals nicer, too.
llvm-svn: 174822
|
|
|
|
|
|
|
|
|
|
|
| |
This correctly formats:
{
a;
}
where { is incorrectly indented by 2, but is at level 0, when
reformatting only 'a;'.
llvm-svn: 174737
|
|
|
|
|
|
| |
Fixes llvm.org/PR14916.
llvm-svn: 174720
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
They are much easier to handle when attached to the previous token.
Before:
unsigned Indent =
formatFirstToken(TheLine.First, IndentForLevel[TheLine.Level] >=
0 ? IndentForLevel[TheLine.Level]
: TheLine.Level * 2, TheLine.InPPDirective, PreviousEndOfLineColumn);
After:
unsigned Indent = formatFirstToken(
TheLine.First, IndentForLevel[TheLine.Level] >= 0
? IndentForLevel[TheLine.Level] : TheLine.Level * 2,
TheLine.InPPDirective, PreviousEndOfLineColumn);
llvm-svn: 174718
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this patch, the formatter introduces 'fake' parenthesis according
to the operator precedence of binary operators.
Before:
return aaaa & AAAAAAAAAAAAAAAAAAAAAAAAAAAAA || bbbb &
BBBBBBBBBBBBBBBBBBBBBBBBBBBBB || cccc & CCCCCCCCCCCCCCCCCCCCCCCCCC ||
dddd & DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD;
f(aaaaaaaaaaaaaaaaaaaa && aaaaaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaa &&
aaaaaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaa && aaaaaaaaaaaaaaaaaaaa);
After:
return aaaa & AAAAAAAAAAAAAAAAAAAAAAAAAAAAA ||
bbbb & BBBBBBBBBBBBBBBBBBBBBBBBBBBBB ||
cccc & CCCCCCCCCCCCCCCCCCCCCCCCCC ||
dddd & DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD;
f(aaaaaaaaaaaaaaaaaaaa && aaaaaaaaaaaaaaaaaaaa,
aaaaaaaaaaaaaaaaaaaa && aaaaaaaaaaaaaaaaaaaa,
aaaaaaaaaaaaaaaaaaaa && aaaaaaaaaaaaaaaaaaaa);
Future improvements:
- Get rid of some of the hacky ways to nicely format certain constructs.
- Merge this parser and the AnnotatingParser as we now have several parsers
that analyze (), [], etc.
llvm-svn: 174714
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
[pboard setData:[NSData dataWithBytes:&button
length:sizeof(button)]
forType:kBookmarkButtonDragType];
After:
[pboard setData:[NSData dataWithBytes:&button length:sizeof(button)]
forType:kBookmarkButtonDragType];
llvm-svn: 174701
|
|
|
|
| |
llvm-svn: 174662
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
const char *test[] = {
// A
"aaaa",
// B
"aaaaa",
};
After:
const char *test[] = {
// A
"aaaa",
// B
"aaaaa",
};
llvm-svn: 174549
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Assign a high penalty to breaking before "<<" if the previous token is a
string literal ending in ":" or "=".
Before:
llvm::outs()
<< "aaaaaaaaaaaaaaaaa = " << aaaaaaaaaaaaaaaaa << "bbbbbbbbbbbbbbbbb = "
<< bbbbbbbbbbbbbbbbb << "ccccccccccccccccc = " << ccccccccccccccccc
<< "ddddddddddddddddd = " << ddddddddddddddddd << "eeeeeeeeeeeeeeeee = "
<< eeeeeeeeeeeeeeeee;
After:
llvm::outs() << "aaaaaaaaaaaaaaaaa = " << aaaaaaaaaaaaaaaaa
<< "bbbbbbbbbbbbbbbbb = " << bbbbbbbbbbbbbbbbb
<< "ccccccccccccccccc = " << ccccccccccccccccc
<< "ddddddddddddddddd = " << ddddddddddddddddd
<< "eeeeeeeeeeeeeeeee = " << eeeeeeeeeeeeeeeee;
llvm-svn: 174545
|
|
|
|
| |
llvm-svn: 174537
|
|
|
|
| |
llvm-svn: 174521
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We now correctly format:
// Written as a macro, it is reformatted from:
#define foo(a) \
do { \
/* Initialize num to zero. */ \
int num = 10; \
/* This line ensures a is never zero. */ \
int i = a == 0 ? 1 : a; \
i = num / i; /* This division is OK. */ \
return i; \
} while (false)
llvm-svn: 174517
|
|
|
|
|
|
|
|
|
| |
We now leave the semicolon in the line of the closing brace in:
namespace {
...
};
llvm-svn: 174514
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes llvm.org/PR15165.
We now correctly align:
[image_rep drawInRect:drawRect
fromRect:NSZeroRect
operation:NSCompositeCopy
fraction:1.0
ssssssssdd:NO
hints:nil];
llvm-svn: 174513
|
|
|
|
|
|
|
| |
This is pretty common in macros:
#define A(X, Y) class X##Y {};
llvm-svn: 174512
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes llvm.org/PR15162.
Before:
bool aaaaaaaaaaaaa = // comment
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa || aaaaaaaaaaaaaaaaaaaaaaaaaaaa ||
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ||
aaaaaaaaaaaaaaaaaaaaaaaaaaaaa;
After:
bool aaaaaaaaaaaaa = // comment
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa || aaaaaaaaaaaaaaaaaaaaaaaaaaaa ||
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa || aaaaaaaaaaaaaaaaaaaaaaaaaaaaa;
llvm-svn: 174508
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this patch, clang-format can analyze the input file for two
properties:
1. Is "int *a" or "int* a" more common.
2. Are non-C++03 constructs used, e.g. A<A<A>>.
With Google-style, clang-format will now use the more common style for
(1) and format C++03 compatible, unless it finds C++11 constructs in the
input.
llvm-svn: 174504
|
|
|
|
|
|
| |
Before: void f(int *a = d *e, int b = 0);
After: void f(int *a = d * e, int b = 0);
llvm-svn: 174500
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Properly handle annotation contexts while calculating extra information
for each token. This enable nested ObjC calls and thus solves (most of)
llvm.org/PR15164. E.g., we can now format:
[contentsContainer replaceSubview:[subviews objectAtIndex:0]
with:contentsNativeView];
Also fix a problem with the formatting of types in casts as this was
trivial now.
llvm-svn: 174498
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. let determineStarAmp() check of unary operators before checking for
"is next '['". That check was added in r173150, and the test from that
revision passes either way.
2. change determineStarAmp() to categorize '*' and '&' after '=' as unary
operator.
3. don't let parseSquare() overwrite the type of a '*' or '&' before the start
of an objc message expression if has the role of unary operator.
llvm-svn: 174489
|
|
|
|
| |
llvm-svn: 174384
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We can now format stuff like:
- (void)doSomethingWith:(GTMFoo *)theFoo
rect:(NSRect)theRect
interval:(float)theInterval {
[myObject doFooWith:arg1 //
name:arg2
error:arg3];
}
This seems to fix everything mentioned in llvm.org/PR14939.
llvm-svn: 174364
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
f(aaaaaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaa +
aaaaaaaaaaaaaaaaaaaa);
aaaaaaa(aaaaaaaaaaaaa, aaaaaaaaaaaaa, aaaaaaaaaaaaa(aaaaaaaaaaaaaaaaa,
aaaaaaaaaaaaaaaa));
After:
f(aaaaaaaaaaaaaaaaaaaa,
aaaaaaaaaaaaaaaaaaaa,
aaaaaaaaaaaaaaaaaaaa + aaaaaaaaaaaaaaaaaaaa);
aaaaaaa(aaaaaaaaaaaaa,
aaaaaaaaaaaaa,
aaaaaaaaaaaaa(aaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaa));
llvm-svn: 174363
|
|
|
|
|
|
|
|
|
|
| |
In preprocessor definitions, we would not parse all the tokens and thus
not annotate them anymore. This led to a wrong formatting of comments
in google style:
#endif // HEADER_GUARD -- requires two spaces
llvm-svn: 174361
|
|
|
|
|
|
| |
This is a follow up to r174309 to actually make it work.
llvm-svn: 174314
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If there are string literals on either side of a '<<', chances are
high that they represent logically separate concepts. Otherwise,
the author could just have just a single literal (possible split
over multiple lines).
So, we can now nicely format things like:
cout << "somepacket = {\n"
<< " val a = " << ValueA << "\n"
<< " val b = " << ValueB << "\n"
<< "}";
llvm-svn: 174310
|
|
|
|
|
|
|
|
|
|
| |
We can now (even in non-bin-packing modes) format:
someFunction(1, /* comment 1 */
2, /* comment 2 */
3, /* comment 3 */
aaa);
llvm-svn: 174309
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Two minor changes:
* Slight penalty for breaking at "," as opposed to ";".
* Don't apply bin-packing rules to for-loops.
Before:
for (int aaaaaa = aaaaaaaaaa; aaaaaa < bbbbbbbb; ++aaaaaa,
++ccccccccccccccc) {}
After:
for (int aaaaaa = aaaaaaaaaa; aaaaaa < bbbbbbbb;
++aaaaaa, ++ccccccccccccccc) {}
llvm-svn: 174308
|
|
|
|
|
|
|
|
|
|
| |
This combines several changes:
* Calculation token type (e.g. for * and &) in the AnnotatingParser.
* Calculate the scope binding strength in the AnnotatingParser.
* Let <> and [] scopes bind stronger than () and {} scopes.
* Add minimal debugging output.
llvm-svn: 174307
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We can now format:
SomeArrayOfSomeType a = { { { 1, 2, 3 } }, { { 1, 2, 3 } },
{ { 111111111111111111111111111111,
222222222222222222222222222222,
333333333333333333333333333333 } },
{ { 1, 2, 3 } }, { { 1, 2, 3 } } };
Before, we did strange things there.
llvm-svn: 174291
|
|
|
|
| |
llvm-svn: 174169
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to end up with good solutions, clang-format needs to try
"all" combinations of line breaks, evaluate them and select the
best one. Before, we have done this using a DFS with memoization
and cut-off conditions. However, this approach is very limited
as shown by the huge static initializer in the attachment of
llvm.org/PR14959.
Instead, this new implementation uses a variant of Dijkstra's
algorithm to do a prioritized BFS over the solution space.
Some numbers:
lib/Format/TokenAnnotator.cpp: 1.5s -> 0.15s
Attachment of PR14959: 10min+ (didn't finish) -> 10s
No functional changes intended.
llvm-svn: 174166
|
|
|
|
|
|
| |
Just put it in one unwrapped line and let the formatter handle it.
llvm-svn: 174063
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Never avoid bin packing in static initializers as this can
lead to terrible results.
2. If an element has to be broken over multiple lines, break after
the following comma.
This should be a step forward, but there are still many cases
especially with nested static initializers that we handle badly.
More patches will follow.
llvm-svn: 174061
|
|
|
|
|
|
| |
No functional changes.
llvm-svn: 173916
|
|
|
|
|
|
|
| |
No functional changes. Also removed experimental-warning from all of
clang-format's files, as it is no longer accurate.
llvm-svn: 173830
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
aaaaaaa(aaaaaa( // comment
aaaaaaa));
<big mess>
After:
aaaaaaa(aaaaaa( // comment
aaaaaaaa));
function(/* parameter 1 */ aaaaaaa,
/* parameter 2 */ aaaaaaa,
/* parameter 3 */ aaaaaaa,
/* parameter 4 */ aaaaaaa);
(the latter example was only wrong in the one-arg-per-line mode, e.g. in
Google style).
llvm-svn: 173821
|
|
|
|
|
|
|
|
|
|
|
|
| |
The style guide only forbids this for function declarations. So,
now
someFunction(
aaaaaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaa, aaaaaaaaaaaa);
Is allowed in Chromium mode.
llvm-svn: 173806
|
|
|
|
|
|
| |
It needs to be compatible with C++03.
llvm-svn: 173805
|
|
|
|
| |
llvm-svn: 173803
|
|
|
|
|
|
|
|
|
|
| |
This is
a) More efficient.
b) Important as we move forward with further metrics for penalty.
No functional changes intended.
llvm-svn: 173801
|
|
|
|
|
|
| |
Not all changes might be ideal, but IMO all are acceptable.
llvm-svn: 173793
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
SomeType aaaaaaaaaaaaaaaaa = aaaaaa->aaaaaaaaaaaaaaaaa(),
aaaaaaaaaaa = aaaaaa->aaaaaaaaaaa();
After:
SomeType aaaaaaaaaaaaaaaaa = aaaaaa->aaaaaaaaaaaaaaaaa(),
aaaaaaaaaaa = aaaaaa->aaaaaaaaaaa();
llvm-svn: 173792
|
|
|
|
|
|
|
| |
This needs some more thinking, e.g. for namespaces, chains of if-else
if, ...
llvm-svn: 173787
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Those empty lines waste vertical whitespace and almost never
increase readability.
Before:
void f() {
DoSomething();
}
After:
void f() {
DoSomething();
}
llvm-svn: 173785
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
for (aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaa = aaaaaaaaaaaaaaa
.aaaaaaaaaaaaaaaa;
aaaaaaaaaaa != aaaaaaaaaaaaaaaaaaa; ++aaaaaaaaaaa) {}
After:
for (aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaa =
aaaaaaaaaaaaaaa.aaaaaaaaaaaaaaaa;
aaaaaaaaaaa != aaaaaaaaaaaaaaaaaaa; ++aaaaaaaaaaa) {}
llvm-svn: 173695
|
|
|
|
|
|
|
|
|
|
| |
This would be against the style guide:
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Function_Declarations_and_Definitions#Function_Declarations_and_Definitions
Not sure what to do as a last resort if the function signature does not
fit onto a single line in Google style ..
llvm-svn: 173690
|