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
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
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
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
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
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
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
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
').' 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
This makes the tedious fitsIntoLimit() method unnecessary and I can
replace one hack (constructor initializers) by a slightly better hack.
Furthermore, this will enable calculating whether a certain part of a
line fits into the limit for future modifications.
llvm-svn: 172604
It was quite convoluted leading to us accidentally introducing O(N^2)
complexity while copying from UnwrappedLine to AnnotatedLine. We might
still want to improve the datastructure in AnnotatedLine (most
importantly not put them in a vector where they need to be copied on
vector resizing but that will be done as a follow-up.
This fixes most of the regression in llvm.org/PR14959.
No formatting changes intended.
llvm-svn: 172602
This is an optimization that djasper spottet. For now, we do not format
anything after the first token that belongs to such an implicit string
literal. All our state is not made for handling that anyway, so we'll
revisit this if we find a problem.
llvm-svn: 172537
Treat tokens inside <> for includes and everything from the second token
of a warning / error on as an implicit string literal, e.g. do not
change its whitespace at all.
Now correctly formats:
#include < path with space >
#error Leave all white!!!!! space* alone!
Note that for #error and #warning we still format the space up to the
first token of the text, so:
# error Text
will become
#error Text
llvm-svn: 172536
Daniel Jasper