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
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
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
We used to incorrectly identify some operators (*, &, +, -, etc.) if
there were comments around them.
Example:
Before: int a = /**/ - 1;
After: int a = /**/ -1;
llvm-svn: 172533
This switches to parsing record definitions only if we can clearly
identify them. We're specifically allowing common patterns for
visibility control through macros and attributes, but we cannot
currently fix all instances. This fixes all known bugs we have though.
Before:
static class A f() {
return g();
} int x;
After:
static class A f() {
return g();
}
int x;
llvm-svn: 172530
We now format this correctly:
Status::Rep Status::global_reps[3] = {
{ kGlobalRef, OK_CODE, NULL, NULL, NULL },
{ kGlobalRef, CANCELLED_CODE, NULL, NULL, NULL },
{ kGlobalRef, UNKNOWN_CODE, NULL, NULL, NULL }
};
- fixed a bug where BreakBeforeClosingBrace would be set on the wrong
state
- added penalties for breaking between = and {, and between { and any
other non-{ token
llvm-svn: 172433
Now, "if (a) return;" is only allowed, if this option is set.
Also add a Chromium style which is currently identical to Google style
except for this option.
llvm-svn: 172431
Before: if (a)
return;
After: if (a) return;
Not yet sure, whether this is always desired, but we can add options and
make this a style parameter as we go along.
llvm-svn: 172413
They work fine, but this fifth use of colons (after labels, in ?:,
in initalizer lists in constructors, in objc method expressions, and in
bitfields) wasn't covered by tests yet.
llvm-svn: 172377
clang-format should not change whether or not there is a line break
before a line comment as this strongly influences the percieved binding.
User input: void f(int a,
// b is awesome
int b);
void g(int a, // a is awesome
int b);
Before: void f(int a, // b is awesome
int b);
void g(int a, // a is awesome
int b);
After: <unchanged from input>
llvm-svn: 172361
Note that I don't know whether we should put {} on a single line in this
case, but it is probably a theoretical issue as in practice such
structs, classes or unions won't be empty.
Before: union A {}
a;
After: union A {} a;
llvm-svn: 172355
I am not aware of a case where that would be wrong. The specific case I
am fixing are function parameters wrapped in parenthesis (e.g. in
macros).
Before: function(a,(b));
After: function(a, (b));
llvm-svn: 172351
A ")" before any of "=", "{" or ";" won't be a cast. This fixes issues
with the formatting of unnamed parameters.
Before: void f(int *){}
After: void f(int *) {}
llvm-svn: 172349
This follows the approach suggested by djasper in PR14911: When a '[' is
seen that's at the start of a line, follows a binary operator, or follows one
of : [ ( return throw, that '[' and its closing ']' are marked as
TT_ObjCMethodExpr and every ':' in that range that isn't part of a ternary
?: is marked as TT_ObjCMethodExpr as well.
Update the layout routines to not output spaces around ':' tokens that are
marked TT_ObjCMethodExpr, and only allow breaking after such tokens, not
before.
Before:
[self adjustButton : closeButton_ ofKind : NSWindowCloseButton];
Now:
[self adjustButton:closeButton_ ofKind:NSWindowCloseButton];
llvm-svn: 172304
