Before (when only reformatting "int b"):
int a; // comment
// comment
int b;
After:
int a; // comment
// comment
int b;
This also fixes llvm.org/PR15433.
llvm-svn: 177524
This seems to be generally more desired.
Before:
if (aaaaaaaa &&
bbbbbbbb >
cccccccc) {}
After:
if (aaaaaaaa &&
bbbbbbbb >
cccccccc) {}
Also: Some formatting cleanup on clang-format's files.
llvm-svn: 177514
clang-format already prevented sequences like:
...
SomeParameter).someFunction(
...
as those are quite confusing. This failed on:
...
SomeParameter).someFunction(otherFunction(
...
Fixed in this patch.
llvm-svn: 177157
Summary:
Do this to avoid spoling nicely formatted multi-line comments (e.g.
with code examples or similar stuff).
Reviewers: djasper
Reviewed By: djasper
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D544
llvm-svn: 177153
Summary:
Aligns continuation lines of multi-line comments to the base
indentation level +1:
class A {
/*
* test
*/
void f() {}
};
The first revision is work in progress. The implementation is not yet complete.
Reviewers: djasper
Reviewed By: djasper
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D541
llvm-svn: 177080
The stronger binding of a string ending in :/= does not really make
sense if it is the only character.
Before:
llvm::outs() << aaaaaaaaaaaaaaaaaaaaaaaa
<< "=" << bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb;
After:
llvm::outs() << aaaaaaaaaaaaaaaaaaaaaaaa << "="
<< bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb;
llvm-svn: 177075
Before:
A = new SomeType * [Length];
A = new SomeType *[Length]();
After:
A = new SomeType *[Length];
A = new SomeType *[Length]();
Small formatting cleanups with clang-format.
llvm-svn: 176936
1. We now ignore all non-default string literals, including raw
literals.
2. We do not break inside escape sequences any more.
FIXME: We still break in trigraphs.
llvm-svn: 176710
With the cursor located at "I", clang-format would not do anything to:
int a;
I
int b;
With this patch, it reduces the number of empty lines as necessary, and
removes unnecessary whitespace. It does not change/reformat "int a;" or
"int b;".
llvm-svn: 176650
With [] marking the selected range, clang-format invoked on
[ ] int a;
Would so far not reformat anything. With this patch, it formats a
line if its leading whitespace is touched.
llvm-svn: 176435
In builder type call, we indent to the laster function calls.
However, for the last element of such a call, we don't need to do
so, as that normally just wastes space and does not increase
readability.
Before:
aaaaaa->aaaaaa->aaaaaa( // break
aaaaaa);
aaaaaaaaaaaaaaaaaaaaa->aaaaaaaaaaaaaaaaaaaaaa
->aaaaaaaaaaaaaaaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
After:
aaaaaa->aaaaaa->aaaaaa( // break
aaaaaa);
aaaaaaaaaaaaaaaaaaaaa->aaaaaaaaaaaaaaaaaaaaaa->aaaaaaaaaaaaaaaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
llvm-svn: 176352
We now break at a slash if we do not find a space to break on.
Also fixes a bug where we would go over the limit when breaking the
second line.
llvm-svn: 176350
If we don't find a natural split point (currently space) in a string
literal protruding over the line, we just split at the last possible
point.
llvm-svn: 176349
Two improvements:
1) Always leave at least one space before "\". Otherwise is can look bad
and there is a risk of unwillingly joining to characters to a different
token.
2) Use the full column limit for single-line #defines.
Fixes llvm.org/PR15148
llvm-svn: 176245
After some discussions, it seems that this is the better path in
the long run. Does not change Chromium style, as there, bin packing
is forbidden by the style guide.
Also fix two minor bugs wrt. formatting:
1. If a call parameter is a function call itself and is split before
the "." or "->", split before the next parameter.
2. If a call parameter is string literal that has to be split onto
two lines, split before the next parameter.
llvm-svn: 176177
Empty lines followed by line comments are often used to highlight the
comment. Empty lines somewhere else are usually left over from manual or
automatic formatting and should probably be removed.
Before (clang-format would keep):
S s = {
a,
b
};
After:
S s = { a, b };
llvm-svn: 176086
We might want to move towards doing this if the formatting can be
significantly improved, but we need to carefully evaluate the different
situations first.
Before (the string literal was split by clang-format here):
aaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaa, aaaaaa("aaa aaaaa aaa aaa aaaaa aaa "
"aaaaa aaa aaa aaaaaa"));
After:
aaaaaaaaaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaa,
aaaaaa("aaa aaaaa aaa aaa aaaaa aaa aaaaa aaa aaa aaaaaa"));
llvm-svn: 176084
This fixes llvm.org/PR15350.
Before:
Constructor(int Parameter = 0)
: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaa),
aaaaaaaaaaaa(aaaaaaaaaaaaaaaaa) {}
After:
Constructor(int Parameter = 0)
: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaa),
aaaaaaaaaaaa(aaaaaaaaaaaaaaaaa) {}
I think the correct solution is to put the VariablePos into
ParenState, not LineState. Added FIXME.
llvm-svn: 176027
In conditional expressions, if the condition is split over multiple
lines, also break before both operands.
This prevents formattings like:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ==
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ? b : c;
Which are bad, because they suggestion incorrect operator precedence:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ==
(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ? b : c);
This lead to the discovery that the expression parser incorrectly
handled conditional operators and that it could also handle semicolons
(which in turn reduced the amount of special casing for for-loops). As a
side-effect, we can now apply the bin-packing configuration to the
sections of for-loops.
llvm-svn: 175973
Also don't break in long include directives as that is not desired.
We can now format:
#include "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
#define LL_FORMAT "ll"
printf("aaaaa: %d, bbbbbbbbb: %" LL_FORMAT "d, cccccccc: %" LL_FORMAT
"d, ddddddddd: %" LL_FORMAT "d\n");
Before, this led to weird results.
llvm-svn: 175959
This fixes llvm.org/PR15033.
Also: Always break before a parameter, if the previous parameter was
split over multiple lines. This was necessary to make the right
decisions in for-loops, almost always makes the code more readable and
also fixes llvm.org/PR14873.
Before:
for (llvm::ArrayRef<NamedDecl *>::iterator I = FD->getDeclsInPrototypeScope()
.begin(), E = FD->getDeclsInPrototypeScope().end();
I != E; ++I) {
}
foo(bar(bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb,
ccccccccccccccccccccccccccccc), d, bar(e, f));
After:
for (llvm::ArrayRef<NamedDecl *>::iterator
I = FD->getDeclsInPrototypeScope().begin(),
E = FD->getDeclsInPrototypeScope().end();
I != E; ++I) {
}
foo(bar(bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb,
ccccccccccccccccccccccccccccc),
d, bar(e, f));
llvm-svn: 175741
We now indent the following correctly:
1. some + "literal" /* comment */
"literal";
2. breaking string literals after which we have another string literal.
llvm-svn: 175628
If the code author decides to put empty lines anywhere into the code we
should treat them equally, i.e. reduce them to the configured
MaxEmptyLinesToKeep.
With this change, we e.g. keep the newline in:
SomeType ST = {
// First value
a,
// Second value
b
};
llvm-svn: 175620
An alternative strategy to calculating the break on demand when hitting
a token that would need to be broken would be to put all possible breaks
inside the token into the optimizer.
Currently only supports breaking at spaces; more break points to come.
llvm-svn: 175613
The key bug was
if (Other.StartOfLineLevel < StartOfLineLevel) ..
instead of
if (Other.StartOfLineLevel != StartOfLineLevel) ..
Also cleaned up the function to be more consistent in the comparisons.
llvm-svn: 175500
In builder-type calls, it can be very confusing to just indent
parameters from the start of the line. Instead, indent 4 from the
correct function call.
Before:
aaaaaaaaaaaaaaaaaaa()->aaaaaa(bbbbb)->aaaaaaaaaaaaaaaaaaa( // break
aaaaaaaaaaaaaa);
aaaaaaaaaaaaaaaaaaaaaaa *aaaaaaaaa = aaaaaa->aaaaaaaaaaaa()->aaaaaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa)
->aaaaaaaaaaaaaaaaa();
After:
aaaaaaaaaaaaaaaaaaa()->aaaaaa(bbbbb)->aaaaaaaaaaaaaaaaaaa( // break
aaaaaaaaaaaaaa);
aaaaaaaaaaaaaaaaaaaaaaa *aaaaaaaaa = aaaaaa->aaaaaaaaaaaa()
->aaaaaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa)
->aaaaaaaaaaaaaaaaa();
llvm-svn: 175444
An unwrapped line can get moved around if there is no newline before
it and the previous line was formatted.
Example:
template<typename T> // Cursor is on this line when hitting "format"
T *getFETokenInfo() const { return static_cast<T*>(FETokenInfo); }
"return .." is the second unwrapped line in this scenario. I does not
touch any reformatted region. Thus, the result of formatting is:
template <typename T> T *getFETokenInfo() const { return static_cast<T *>(FETokenInfo); }
After second format (and arguably desired end-result):
template <typename T> T *getFETokenInfo() const {
return static_cast<T *>(FETokenInfo);
}
This fixes: llvm.org/PR15060.
llvm-svn: 175440
This fixes llvm.org/PR15248.
Before:
Test::Test(int b) : a(b *b) {}
for (int i = 0; i < a *a; ++i) {}
After:
Test::Test(int b) : a(b * b) {}
for (int i = 0; i < a * a; ++i) {}
llvm-svn: 175439
The current heuristic assumes that there can't be binary operators in
builder-type calls (excluding assigments). However, it also excluded
< and > in general, which is wrong. Now they are only excluded if they
are template parameters.
Before:
return aaaaaaaaaaaaaaaaa->aaaaa().aaaaaaaaaaaaa()i
.aaaaaa() < aaaaaaaaaaaaaaaaaaa->aaaaa().aaaaaaaaaaaaa().aaaaaa();
After:
return aaaaaaaaaaaaaaaaa->aaaaa().aaaaaaaaaaaaa().aaaaaa() <
aaaaaaaaaaaaaaaaaaa->aaaaa().aaaaaaaaaaaaa().aaaaaa();
llvm-svn: 175291
This got lost and was untested as the same effect is achieved by
avoiding bin packing, which is active in Google style by default.
However, moving forward, we want more control over the bin packing
option(s) and thus, this flag should work as expected.
llvm-svn: 175277
This is almost always more readable.
Before:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
? aaaaaaaaaaaaaaaaaaaaaaaaaaa : aaaaaaaaaaaaaaaaaaaaaaaaaaa;
After:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
? aaaaaaaaaaaaaaaaaaaaaaaaaaa
: aaaaaaaaaaaaaaaaaaaaaaaaaaa;
llvm-svn: 175262
Before:
aaaaaaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa()
.aaaaaaaaaaaaaaaaa());
After:
aaaaaaaaaaaaaaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa().aaaaaaaaaaaaaaaaa());
Not sure which of the formattings above is better, but we should not pick
one by accident.
llvm-svn: 175165
This gives a clearer separation of the context, e.g. in GMOCK
statements.
Before:
EXPECT_CALL(SomeObject,
SomeFunction(Parameter)).WillRepeatedly(Return(SomeValue));
After:
EXPECT_CALL(SomeObject, SomeFunction(Parameter))
.WillRepeatedly(Return(SomeValue));
Minor format cleanups.
llvm-svn: 175162
So far, clang-format has always assumed the whitespace belonging to the
subsequent token. This has the negative side-effect that when
clang-format formats a line, it does not remove its trailing whitespace,
as it belongs to the next token.
Thus, this patch fixes most of llvm.org/PR15062.
We are not zapping a file's trailing whitespace so far, as this does not
belong to any token we see during formatting. We need to fix this in a
subsequent patch.
llvm-svn: 175152
The formatter can now format:
void aaaaaaaaaaaaaaaaaa(int level,
double *min_x,
double *max_x,
double *min_y,
double *max_y,
double *min_z,
double *max_z, ) {
}
Although this is invalid code, it frequently happens during development and
clang-format should be nicer :-).
llvm-svn: 175151
This fixes llvm.org/PR15179.
Before:
class ColorChooserMac : public content::ColorChooser,
public content::WebContentsObserver {
};
After:
class ColorChooserMac : public content::ColorChooser,
public content::WebContentsObserver {
};
llvm-svn: 175147
This has so far been disabled for Google style, but should be done
before breaking at nested name specifiers or in template parameters.
Before (in Google style):
template <typename T>
aaaaaaaa::aaaaa::aaaaaa<T, aaaaaaaaaaaaaaaaaaaaaaaaa> aaaaaaaaaaaaaaaaaaaaaaaa<
T>::aaaaaaa() {}
After:
template <typename T>
aaaaaaaa::aaaaa::aaaaaa<T, aaaaaaaaaaaaaaaaaaaaaaaaa>
aaaaaaaaaaaaaaaaaaaaaaaa<T>::aaaaaaa() {}
llvm-svn: 175074
- clear ownership: the SpecificBumpPtrAllocator owns all StateNodes
- this allows us to simplify the memoization data structure into a
std::set (FIXME: figure out whether we want to use a hash based
data structure).
- introduces StateNode as recursive data structure, instead of using
Edge and the Seen-map combined to drill through the graph
- using a count to stabilize the penalty instead of relying on the
container
- pulled out a method to forward-apply states in the end
This leads to a ~40% runtime decrease on Nico's benchmark.
Main FiXME is that the parameter lists of some function get too long.
I'd vote for either pulling the Queue etc into the Formatter proper,
or creating an inner class just for the search algorithm.
llvm-svn: 175051
Still the formatting can be improved, but at least we don't assert any
more. This happened when trying to format lib/Sema/SemaType.cpp.
llvm-svn: 175003
This redoes how '*' and '&' are classified as pointer / reference markers when
followed by ')', '>', or ','.
Previously, determineStarAmpUsage() marked a single '*' and '&' followed by
')', '>', or ',' as pointer or reference marker. Now, all '*'s and '&'s
preceding ')', '>', or ',' are marked as pointer / reference markers. Fixes
PR14884.
Since only the last '*' in 'int ***' was marked as pointer before (the rest
were unary operators, which don't reach spaceRequiredBetween()),
spaceRequiredBetween() now had to be thought about handing multiple '*'s in
sequence.
Before:
return sizeof(int * *);
Type **A = static_cast<Type * *>(P);
Now:
return sizeof(int**);
Type **A = static_cast<Type **>(P);
While here, also make all methods of AnnotatingParser except parseLine()
private.
Review URL: http://llvm-reviews.chandlerc.com/D384
llvm-svn: 174975
Before:
for (id foo in[self getStuffFor : bla]) {
}
Now:
for (id foo in [self getStuffFor:bla]) {
}
"in" is treated as loop keyword if the line starts with "for", and as a
regular identifier else. To check for "in", its IdentifierInfo is handed
through a few layers.
llvm-svn: 174889
In google style, trailing comments are separated by two spaces. This
patch fixes the counting of these spaces and prevents clang-format from
creating a line with 81 columns.
llvm-svn: 174879
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
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
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
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
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
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
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
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
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
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
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
The style guide only forbids this for function declarations. So,
now
someFunction(
aaaaaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaa, aaaaaaaaaaaa);
Is allowed in Chromium mode.
llvm-svn: 173806
Before (in good cases):
for (auto aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa) {}
for (auto aaaaaaaaaaaaaaaaaaaa : aaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaa,
aaaa)) {}
After:
for (auto aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa :
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa) {}
for (auto aaaaaaaaaaaaaaaaaaaa :
aaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaa, aaaa)) {}
llvm-svn: 173684
Before we did not really systematically format those. Now, we format the
different cases as:
- 1 Line: a ? b : c;
- 2 Lines: short ? loooooooooong
: loooooooooong
- 2 Lines: loooooooooooooooong
? short : short
- 3 Lines: loooooooooooooooong
? loooooooooooooong
: loooooooooooooong
Not sure whether "?" and ":" should go on the new line, but it seems to
be the most consistent approach.
llvm-svn: 173683
1. Use a hanging ident for function calls nested in binary expressions.
E.g.:
int aaaaa = aaaaaaaaa && aaaaaaaaaa(
aaaaaaaaaa);
2. Slightly improve heuristic for builder type expressions and reduce
penalty for breaking before "." and "->" in those.
3. Remove mostly obsolete metric of decreasing indent level. This
fixes: llvm.org/PR14931.
Changes #1 and #2 were necessary to keep tests passing after #3.
llvm-svn: 173680
These always represent a continuation and we should increase the ident.
Before:
aaaaaaaaa(aaaaaaaaaaaaaaaaaaaaa::
aaaaaaaaaaaaaaaaaaaa);
After:
aaaaaaaaa(aaaaaaaaaaaaaaaaaaaaa::
aaaaaaaaaaaaaaaaaaaa);
llvm-svn: 173675
This combines two small changes:
1) Put a penalty on breaking after "<"
2) Only produce a hanging indent when parameters are separated by
commas.
Before:
aaaaaaaaaaaaaaaaaaaaaaaa<
aaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaa>(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
aaaaaa(new Aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaaaaaaaaaaa));
After:
aaaaaaaaaaaaaaaaaaaaaaaa<aaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaa>(
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
aaaaaa(new Aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaaaaaaaaaaa));
This changes one ObjC test, but AFAICT this is not according to any
style guide (neither before nor after). We probably should be aligning
on the ":" there according to:
http://google-styleguide.googlecode.com/svn/trunk/objcguide.xml?showone=Method_Invocations#Method_Invocations
llvm-svn: 173457
Otherwise, really long nested name specifiers can easily lead to a
violation of the column limit.
Not sure about the rules for indentation in those cases, so input is
appreciated (see tests.).
llvm-svn: 173438
Before:
int aaaa = aaaaa().aaaaa() // force break
.aaaaa();
After:
int aaaa = aaaaa().aaaaa() // force break
.aaaaa();
The other indent is just wrong and confusing.
llvm-svn: 173273
Before:
bool aaaa = aaaaaaaaaaa(
aaaaaaaaaaaaaaaaa);
After:
bool aaaa = aaaaaaaaaaa(
aaaaaaaaaaaaaaaaa);
The other indentation was a nice attempt but doesn't work in many cases.
Not sure what the right long term solution is as the "After: " is still
not nice. We either need to figure out what to do in the cases where it
"doesn't work" or come up with a third solution, e.g. falling back to:
bool aaaa =
aaaaaaaaaaa(
aaaaaaaaaaaaaaaaa);
which should always work and nicely highlight the structure.
llvm-svn: 173268
Layouting would prevent breaking before + in
a[b + c] = d;
Regression detected by code review.
Also fixes an invalid-read found by the valgrind bot.
llvm-svn: 173262
Having seen more cases, this actually was not a good thing to do in the
first place. We can still improve on what we do now, but breaking after
the "=" is good in many cases.
Before:
aaaaaaaaaaaaa = aa->aaaaaaaaaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaa));
After:
aaaaaaaaaaaaa =
aa->aaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaa));
llvm-svn: 173257
Before: if (int * a = &b) ...
After: if (int *a = &b) ...
Also changed all the existing tests to test the expressions in question
both in a declaration and in an expression context.
llvm-svn: 173256
We will need a more principled solution, but we should not leave this
unfixed until we come up with one.
Before: void f() { int * a; }
After: void f() { int *a; }
llvm-svn: 173252
This only affects styles where BinPackParameters is false.
With AllowAllParametersOnNextLine:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(
aaaaaaaaaa, aaaaaaaaaa, aaaaaaaaaa, aaaaaaaaaaa, aaaaaaaaaaa);
Without it:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(aaaaaaaaaa,
aaaaaaaaaa,
aaaaaaaaaa,
aaaaaaaaaaa,
aaaaaaaaaaa);
llvm-svn: 173246
This gives us the ability to guess better defaults for whether a *
between identifiers is a pointer dereference or binary operator.
Now correctly formats:
void f(a *b);
void f() { f(a * b); }
llvm-svn: 173243
Changing nextToken() in the UnwrappedLineParser to get the next
non-comment token. This allows us to correctly layout a whole class of
snippets, like:
if /* */(/* */ a /* */) /* */
f() /* */; /* */
else /* */
g();
Fixes a bug in the formatter where we would assume there is a previous
non-comment token.
Also adds the indent level of an unwrapped line to the debug output in
the parser.
llvm-svn: 173168
We used to align trailing comments belong to different things.
Before:
void f() { // some function..
}
int a; // some variable..
After:
void f() { // some function..
}
int a; // some variable..
llvm-svn: 173100
Very similar to what we do for record definitions:
- tighten down what is an enum definition, so that we don't mistake a
function for an enum
- allow common idioms around declarations (we'll want to handle that
more centrally in the future)
We now correctly format:
enum X f() {
a();
return 42;
}
llvm-svn: 173075
We now only put empty blocks into a single line, if all of:
- all tokens of the structural element fit into a single line
- we're not in a control flow statement
Note that we usually don't put record definitions into a single line, as
there's usually at least one more token (the semicolon) after the
closing brace. This doesn't hold when we are in a context where there is
no semicolon, like "enum E {}".
There were some missing tests around joining lines around the corner
cases of the allowed number of columns, so this patch adds some.
llvm-svn: 173055
Before: template <template <typename T>, typename P > class X;
After: template <template <typename T>, typename P> class X;
More importantly, the token annotations for the second ">" are now computed
correctly.
llvm-svn: 173047
Previously, we would not detect brace initializer lists in return
statements, thus:
return (a)(b) { 1, 2, 3 };
would put the semicolon onto the next line.
llvm-svn: 173017
Manually fix the order of UnwrappedLineParser.cpp as that one didn't
have its associated header as the first header.
This also uncovered a subtle inclusion order dependency as CLog.h didn't
include LLVM.h to pick up using declarations it relied upon.
llvm-svn: 172892
This patch prepares being able to test for and fix more problems (see
FIXME in the test for example).
Previously we would output unwrapped lines for preprocessor directives
at the point where we also parsed the hash token. Since often
projections only terminate (and thus output their own unwrapped line)
after peeking at the next token, this would lead to the formatter seeing
the preprocessor directives out-of-order (slightly earlier). To be able
to correctly identify lines to merge, the formatter needs a well-defined
order of unwrapped lines, which this patch introduces.
llvm-svn: 172819
').' is likely part of a builder pattern statement.
This is based upon a patch developed by Nico Weber. Thank you!
Before:
int foo() {
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:
int foo() {
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);
}
Probably not ideal, but makes many cases much more readable.
The changes to overriding-ftemplate-comments.cpp don't seem better or
worse. We should address those soon.
llvm-svn: 172804
It's generally not possible to know if 'a' '*' 'b' is a multiplication
expression or a variable declaration with a purely lexer-based approach. The
formatter currently uses a heuristic that classifies this token sequence as a
multiplication in rhs contexts (after '=' or 'return') and as a declaration
else.
Because of this, it gets bit tests in ifs, such as "if (a & b)" wrong. However,
declarations in ifs always have to be followed by '=', so this patch changes
the formatter to classify '&' as an operator if it's at the start of an if
statement.
Before:
if (a& b)
if (int* b = f())
Now:
if (a & b)
if (int* b = f())
llvm-svn: 172731
Also adding more tests.
We can now keep the formatting of something like:
static SomeType type = { aaaaaaaaaaaaaaaaaaaa, /* comment */
aaaaaaaaaaaaaaaaaaaa /* comment */,
/* comment */ aaaaaaaaaaaaaaaaaaaa,
aaaaaaaaaaaaaaaaaaaa, // comment
aaaaaaaaaaaaaaaaaaaa };
Note that the comment in the first line is handled like a trailing line comment
as that is likely what the user intended.
llvm-svn: 172711
Before: Constructor() : a(a), // comment a(a) {}
After: Constructor() : a(a), // comment
a(a) {}
Needed this as a quick fix. Will add more tests for this in a future
commit.
llvm-svn: 172624
We used to incorrectly parse
aaaaaa ? aaaaaa(aaaaaa) : aaaaaaaa;
Due to an l_paren being followed by a colon, we assumed it to be part of
a constructor initializer. Thus, we never found the colon belonging to
the conditional expression, marked the line as bing incorrect and did
not format it.
llvm-svn: 172621
"Bin-packing" here means allowing multiple parameters on one line, if a
function call/declaration is spread over multiple lines.
This is required by the Chromium style guide and probably desired for
the Google style guide. Not making changes to LLVM style as I don't have
enough data.
With this enabled, we format stuff like:
aaaaaaaaaaaaaaa(aaaaaaaaaa,
aaaaaaaaaa,
aaaaaaaaaaaaaaaaaaaaaaa).aaaaaaaaaaaaaaaaaa();
llvm-svn: 172617
Leave a quick "// Uncomment this." hint to enable the debug output in
tests. FIXME: figure out whether we want to enable debug command line
handling for all tests.
llvm-svn: 172608
Daniel Jasper