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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174879 91177308-0d34-0410-b5e6-96231b3b80d8
Now correctly formats:
#define A \
\
b;
to
#define A b;
Added the state whether an unwrapped line is a macro to the debug
output.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174878 91177308-0d34-0410-b5e6-96231b3b80d8
This correctly formats:
{
a;
}
where { is incorrectly indented by 2, but is at level 0, when
reformatting only 'a;'.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174737 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174714 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174504 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174364 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174307 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174166 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174061 91177308-0d34-0410-b5e6-96231b3b80d8
No functional changes. Also removed experimental-warning from all of
clang-format's files, as it is no longer accurate.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173830 91177308-0d34-0410-b5e6-96231b3b80d8
The style guide only forbids this for function declarations. So,
now
someFunction(
aaaaaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaa, aaaaaaaaaaaa);
Is allowed in Chromium mode.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173806 91177308-0d34-0410-b5e6-96231b3b80d8
This is
a) More efficient.
b) Important as we move forward with further metrics for penalty.
No functional changes intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173801 91177308-0d34-0410-b5e6-96231b3b80d8
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)) {}
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173684 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173683 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173680 91177308-0d34-0410-b5e6-96231b3b80d8
These always represent a continuation and we should increase the ident.
Before:
aaaaaaaaa(aaaaaaaaaaaaaaaaaaaaa::
aaaaaaaaaaaaaaaaaaaa);
After:
aaaaaaaaa(aaaaaaaaaaaaaaaaaaaaa::
aaaaaaaaaaaaaaaaaaaa);
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173675 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173457 91177308-0d34-0410-b5e6-96231b3b80d8
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.).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173438 91177308-0d34-0410-b5e6-96231b3b80d8
Before:
int aaaa = aaaaa().aaaaa() // force break
.aaaaa();
After:
int aaaa = aaaaa().aaaaa() // force break
.aaaaa();
The other indent is just wrong and confusing.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173273 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173268 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173262 91177308-0d34-0410-b5e6-96231b3b80d8
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));
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173257 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173256 91177308-0d34-0410-b5e6-96231b3b80d8
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; }
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173252 91177308-0d34-0410-b5e6-96231b3b80d8
This only affects styles where BinPackParameters is false.
With AllowAllParametersOnNextLine:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(
aaaaaaaaaa, aaaaaaaaaa, aaaaaaaaaa, aaaaaaaaaaa, aaaaaaaaaaa);
Without it:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(aaaaaaaaaa,
aaaaaaaaaa,
aaaaaaaaaa,
aaaaaaaaaaa,
aaaaaaaaaaa);
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173246 91177308-0d34-0410-b5e6-96231b3b80d8
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); }
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173243 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173168 91177308-0d34-0410-b5e6-96231b3b80d8
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..
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173100 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173055 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173047 91177308-0d34-0410-b5e6-96231b3b80d8
When trying to merge lines, we should not touch lines that are invalid,
as we don't know how long they might be.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173043 91177308-0d34-0410-b5e6-96231b3b80d8
').' 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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172804 91177308-0d34-0410-b5e6-96231b3b80d8
Before:
#include <a> // for x
#include <a/b/c> // for yz
After:
#include <a> // for x
#include <a/b/c> // for yz
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172799 91177308-0d34-0410-b5e6-96231b3b80d8
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())
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172731 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172711 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172624 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172621 91177308-0d34-0410-b5e6-96231b3b80d8
Various reasons seem to speak against it, so I am disabling this for
now.
Changed tests to still test this option.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172618 91177308-0d34-0410-b5e6-96231b3b80d8
"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();
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172617 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172604 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172602 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172537 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172536 91177308-0d34-0410-b5e6-96231b3b80d8
We used to incorrectly identify some operators (*, &, +, -, etc.) if
there were comments around them.
Example:
Before: int a = /**/ - 1;
After: int a = /**/ -1;
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172533 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172433 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172431 91177308-0d34-0410-b5e6-96231b3b80d8
If the first line of a merge would exactly fit into the column limit,
an unsigned overflow made us not break.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172426 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172413 91177308-0d34-0410-b5e6-96231b3b80d8
Main difference, add an AnnotatedLine class to hold information about a
line while formatting. At the same time degrade the UnwrappedLine class
to a class solely used for communicating between the UnwrappedLineParser
and the Formatter.
No functional changes intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172403 91177308-0d34-0410-b5e6-96231b3b80d8
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>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172361 91177308-0d34-0410-b5e6-96231b3b80d8
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));
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172351 91177308-0d34-0410-b5e6-96231b3b80d8
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 *) {}
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172349 91177308-0d34-0410-b5e6-96231b3b80d8
canBreakBefore() does not allow breaking after ':' for LT_ObjCMethodDecl lines,
so if Newline is true in addTokenToState() for ':' then LT_ObjCMethodDecl
cannot be set. No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172307 91177308-0d34-0410-b5e6-96231b3b80d8
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];
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172304 91177308-0d34-0410-b5e6-96231b3b80d8
Before:
void aaaaaaaaaaaa(int aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa) GUARDED_BY(
aaaaaaaaaaaaa);
After:
void aaaaaaaaaaaa(int aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa)
GUARDED_BY(aaaaaaaaaaaaa);
Also did some formatting cleanups with clang-format on the way.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172200 91177308-0d34-0410-b5e6-96231b3b80d8
Added option to put each constructor initializer on its own line
if not all initializers fit on a single line. Enabling this for
Google style now as the style guide (arguable) suggests it. Not
sure whether we also want it for LLVM.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172196 91177308-0d34-0410-b5e6-96231b3b80d8
As we keep adding more stuff to it, this structure is easier to
maintain. At one point we might think about making it an actual
class with specific accessors, etc.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172188 91177308-0d34-0410-b5e6-96231b3b80d8
Objective-C method declarations look like this:
- (returntype)name:(type)argname anothername:(type)arg2name;
In google style, there's no space after the leading '-' but one after
"(returntype)" instead (but none after the argument types), see
http://google-styleguide.googlecode.com/svn/trunk/objcguide.xml#Method_Declarations_and_Definitions
Not inserting the space after '-' is easy, but to insert the space after the
return type, the formatter needs to know that a closing parenthesis ends the
return type. To do this, I tweaked the code in parse() to check for this, which
in turn required moving detection of TT_ObjCMethodSpecifier from annotate() to
parse(), because parse() runs before annotate().
(To keep things interesting, the return type is optional, but it's almost
always there in practice.)
http://llvm-reviews.chandlerc.com/D280
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172140 91177308-0d34-0410-b5e6-96231b3b80d8
Before:
@property(assign, getter = isEditable) BOOL editable;
Now:
@property(assign, getter=isEditable) BOOL editable;
It'd be nice if some Apple person could let me know if spaces are preferred
around '=' in @synthesize lines (see FIXME in the test).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172110 91177308-0d34-0410-b5e6-96231b3b80d8
The first token in @implementation, @interface, and @protocol lines is now
marked TT_ObjCDecl, and lines starting with a TT_ObjCDecl token are now marked
LT_ObjCMethodDecl.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172093 91177308-0d34-0410-b5e6-96231b3b80d8
This prepares the code for single line optimizations and changes the
dependencies between single-line-formats to the indent of the first
token.
Conceptually, the first token is "between" the lines anyway, as the
whitespace for the first token includes the previous end-of-line, which
needs to be escaped when inside a preprocessor directive.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172083 91177308-0d34-0410-b5e6-96231b3b80d8
We now decide whether a newline should go before the closing brace
depending on whether a newline was inserted after the opening brace.
For example, we now insert a newline before '};' in:
static SomeClass WithALoooooooooooooooooooongName = {
100000000, \"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\"
};
... while not inserting a newline here:
static SomeClass = { a, b, c, d, e, f, g, h, i, j,
looooooooooooooooooooooooooooooooooongname,
looooooooooooooooooooooooooooooong };
Also fixes the formating of (column limit 25):
int x = {
avariable,
b(alongervariable)
};
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172076 91177308-0d34-0410-b5e6-96231b3b80d8
We're now formatting (column limit 25):
int x = {
avariable,
b(alongervariable) };
This also fixes:
Aaa({
int i;
}, aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb,
ccccccccccccccccc));
... where we would previously break after the '},'.
Putting the closing curly into an extra line when there's a break
directly after the first curly will be done in a subsequent patch.
Paired with djasper.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172070 91177308-0d34-0410-b5e6-96231b3b80d8
Before: int (^myBlock) (int) = ^(int num) {}
A<void ()>;
int (*b)(int);
After: int (^myBlock)(int) = ^(int num) {}
A<void()>;
int(*b)(int);
For function types and function pointer types, this patch only makes
the behavior consistent (for types that are keywords and other types).
For the latter function pointer type declarations, we'll probably
want to add a space after "int".
Also added LangOpts.Bool = 1, so we handle "A<bool()>" appropriately
Moved the LangOpts-settings to a public place for use by tests
and clang-format binary.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172065 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, we would not indent:
SOME_MACRO({
int i;
});
correctly. This is fixed by adding the trailing }); to the unwrapped
line starting with SOME_MACRO({, so the formatter can correctly match
the braces and indent accordingly.
Also fixes incorrect parsing of initializer lists, like:
int a[] = { 1 };
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172058 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes llvm.org/PR14684.
Before: int *pa = (int *) & a;
After: int *pa = (int *)&a;
We still don't understand all kinds of casts. I added a FIXME to
address that.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172056 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes llvm.org/PR14883, where clang-format would run into an
assertion on:
void f() { return } 42
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@172049 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, we'd always start at indent level 0 after a preprocessor
directive, now we layout the following snippet (column limit 69) as
follows:
functionCallTo(someOtherFunction(
withSomeParameters, whichInSequence,
areLongerThanALine(andAnotherCall,
B
withMoreParamters,
whichStronglyInfluenceTheLayout),
andMoreParameters),
trailing);
Note that the different jumping indent is a different issue that will be
addressed separately.
This is the first step towards handling #ifdef->#else->#endif chains
correctly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171974 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes llvm.org/PR14870 and we no longer mess up:
template <typename T1, typename T2 = char, typename T3 = char,
typename T4 = char>
void f();
It removes the nice aligment for assignments inside other expressions,
but I am not sure those are actually practically relevant. If so, we can
fix those later.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171966 91177308-0d34-0410-b5e6-96231b3b80d8
This addresses llvm.org/PR14847.
We can now format something like:
int aaaaaaaaaaaaaaaaaaaaaaaaaaa =
// aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaiaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+ bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb;
clang-format unavoidably exceeds the column limit, but does not just
flush everything into a single line. Moreover, it tries to minimize the
number of characters beyond the column limit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171964 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes llvm.org/PR14860.
Before, we messed up the format of:
if (DeclaratorInfo.isFunctionDeclarator() &&
//getDeclSpecContextFromDeclaratorContext(Context) == DSC_top_level &&
Tok.is(tok::semi) && NextToken().is(tok::l_brace)) {
}
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171961 91177308-0d34-0410-b5e6-96231b3b80d8
Before: int ( ^ Block1) (int, int) = ^ (int i, int j)
After: int (^Block1) (int, int) = ^(int i, int j)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171959 91177308-0d34-0410-b5e6-96231b3b80d8
This addresses llvm.org/PR14864.
We used to completely mess this up and now format as:
Diag(NewFD->getLocation(),
getLangOpts().MicrosoftExt ? diag::ext_function_specialization_in_class :
diag::err_function_specialization_in_class)
<< NewFD->getDeclName();
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171957 91177308-0d34-0410-b5e6-96231b3b80d8
In Clang/LLVM this seems to be the more common formatting for ##s. There
might still be case that we miss, but we'll fix those as we go along.
Before:
#define A(X)
void function ## X();
After:
#define A(X)
void function##X();
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171862 91177308-0d34-0410-b5e6-96231b3b80d8
This is a first step towards supporting more complex structures such
as #ifs inside unwrapped lines. This patch mostly converts the array-based
UnwrappedLine into a linked-list-based UnwrappedLine. Future changes will
allow multiple children for each Token turning the UnwrappedLine into a
tree.
No functional changes intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171856 91177308-0d34-0410-b5e6-96231b3b80d8
This should make it slightly more readable as it more clearly separates
what happens where. No intended functional changes. More of this to
come..
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171748 91177308-0d34-0410-b5e6-96231b3b80d8
This addresses llvm.org/PR14830.
Before:
unsigned Cost =
TTI.getMemoryOpCost(I->getOpcode(), VectorTy, SI->getAlignment(),
SI->getPointerAddressSpace());
CharSourceRange LineRange =
CharSourceRange::getTokenRange(TheLine.Tokens.front().Tok.getLocation(),
TheLine.Tokens.back().Tok.getLocation());
After:
unsigned Cost = TTI.getMemoryOpCost(I->getOpcode(), VectorTy,
SI->getAlignment(),
SI->getPointerAddressSpace());
CharSourceRange LineRange = CharSourceRange::getTokenRange(
TheLine.Tokens.front().Tok.getLocation(),
TheLine.Tokens.back().Tok.getLocation());
This required rudimentary changes to static initializer lists, but we
are not yet formatting them in a reasonable way. That will be done in a
subsequent patch.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171731 91177308-0d34-0410-b5e6-96231b3b80d8
Before:
virtual void write(ELFWriter *writer, OwningPtr<FileOutputBuffer> &buffer) =
0
After:
virtual void write(ELFWriter *writerrr,
OwningPtr<FileOutputBuffer> &buffer) = 0;
This addresses llvm.org/PR14815.
To implement this I introduced a line type during parsing and moved the
definition of TokenType out of the struct for increased readability.
Should have done the latter in a separate patch, but it would be hard to
pull apart now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171724 91177308-0d34-0410-b5e6-96231b3b80d8
We would format:
#define A \
int f(a); int i;
as
#define A \
int f(a);\
int i
The fix will break up macro definitions that could fit a line, but hit
the last column; fixing that is more involved, though, as it requires
looking at the following line.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171715 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, we'd format
int i;\
// comment
as
int i; // comment
The problem is that the escaped newline is part of the next token, and
thus the raw token text of the comment doesn't start with "//".
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171713 91177308-0d34-0410-b5e6-96231b3b80d8
If a token follows directly on an escaped newline, the escaped newline
is stored with the token. Since we re-layout escaped newlines, we need
to treat them just like normal whitespace - thus, we need to increase
the whitespace-length of the token, while decreasing the token length
(otherwise the token length contains the length of the escaped newline
and we double-count it while indenting).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171706 91177308-0d34-0410-b5e6-96231b3b80d8
To parse # correctly, we need to know whether it is the first token in a
line - we can deduct this either from the whitespace or seeing that the
token is the first in the file - we already calculate this information.
This patch moves the identification of the first token into the
getNextToken method and stores it inside the FormatToken, so the
UnwrappedLineParser can stay independent of the SourceManager.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171640 91177308-0d34-0410-b5e6-96231b3b80d8
Some of this is still pretty rough (note the load of FIXMEs), but it is
strictly an improvement and fixes various bugs that were related to
macro processing but are also imporant in non-macro use cases.
Specific fixes:
- correctly puts espaced newlines at the end of the line
- fixes counting of white space before a token when escaped newlines are
present
- fixes parsing of "trailing" tokens when eof() is hit
- puts macro parsing orthogonal to parsing other structure
- general support for parsing of macro definitions
Due to the fix to format trailing tokens, this change also includes a
bunch of fixes to the c-index tests.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171556 91177308-0d34-0410-b5e6-96231b3b80d8
Fixes:
- incorrect handling of multiple consecutive preprocessor directives
- crash when trying to right align the escpaed newline for a line that
is longer than the column limit
- using only ColumnLimit-1 columns when layouting with escaped newlines
inside preprocessor directives
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171401 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes llvm.org/PR14786.
We will need to split there as a last resort, but that should be done
consistently independent of whether the type is a template type or not.
Before:
template <typename T>
aaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaaaaaaaa<T>
::aaaaaaaaaa, aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
After:
template <typename T>
aaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaa,
aaaaaaaaaaaaaaaaaaaaaaaaaa<T>::aaaaaaaaaa,
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171400 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes llvm.org/PR14687.
Also fixes segfault for lines starting with * or &.
Before:
a *~b;
*a = 1; // <- this segfaulted
After:
a * ~b;
*a = 1; // no segfault :-)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171396 91177308-0d34-0410-b5e6-96231b3b80d8
This is the first step towards handling preprocessor directives. This
patch only fixes the most pressing issue, namely correctly escaping
newlines for tokens within a sequence of a preprocessor directive.
The next step will be to fix incorrect format decisions on #define
directives.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171393 91177308-0d34-0410-b5e6-96231b3b80d8
Removes a duplicate #include as well as cleaning up some sort order
regressions since I last ran the script over Clang.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171364 91177308-0d34-0410-b5e6-96231b3b80d8
Apply all formatting changes that clang-format would apply to its own source
code. All choices seem to improve readability (or at least not make it worse).
No functional changes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171039 91177308-0d34-0410-b5e6-96231b3b80d8
This prevents formattings like this (assuming "parameter" doesn't fit the line):
bool f = someFunction() && someFunctionWithParam(
parameter) && someOtherFunction();
Here, "parameter" - the start of line 2 - has a parenthesis level of 2, but
there are subsequent tokens ("&&" and "someOtherFunction") with a lower level.
This is bad for readability as "parameter" hides "someOtherFunction". With this
patch, this changes to:
bool f = someFunction() &&
someFunctionWithParam(parameter) &&
someOtherFunction();
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171038 91177308-0d34-0410-b5e6-96231b3b80d8
This changes:
int Result = a + // force break
b;
return Result + // force break
5;
To:
int Result = a + // force break
b;
return Result + // force break
5;
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171032 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes llvm.org/pr14686.
We used to add too many spaces for different versions of overloaded operator
function declarations/definitions. This patch changes, e.g.
operator *() {}
operator >() {}
operator () () {}
to
operator*() {}
operator>() {}
operator()() {}
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171028 91177308-0d34-0410-b5e6-96231b3b80d8
With this patch, splitting after binary operators has a panelty corresponding
to the operator's precedence. We used to ignore this and eagerly format like:
if (aaaaaaaaaaaaaaaaaaaaaaaaa || bbbbbbbbbbbbbbbbbbbbbbbbb &&
ccccccccccccccccccccccccc) { .. }
With this patch, this becomes:
if (aaaaaaaaaaaaaaaaaaaaaaaaa ||
bbbbbbbbbbbbbbbbbbbbbbbbb && ccccccccccccccccccccccccc) { .. }
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171007 91177308-0d34-0410-b5e6-96231b3b80d8
"return a*b;" was formatted as "return a *b;" and is now formatted as "return a * b;".
Fixes PR14687 partially.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@170993 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes PR14683. We used to format like this:
#include <a / b>
And this patch changes this to:
#include <a/b>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@170910 91177308-0d34-0410-b5e6-96231b3b80d8
We used to not really format them. Now we do:
for (MachineBasicBlock::succ_iterator SI = BB->succ_begin(),
SE = BB->succ_end();
SI != SE; ++SI) {
This is just one example and I am sure we still mess some of them up, but it
is a step forward.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@170899 91177308-0d34-0410-b5e6-96231b3b80d8
We used to format initializers like this (with a sort of hacky implementation):
Constructor()
: Val1(A),
Val2(B) {
and now format like this (with a somewhat better solution):
Constructor()
: Val1(A), Val2(B) {
assuming this would not fit on a single line. Also added tests.
As a side effect we now first analyze whether an UnwrappedLine needs to be
split at all. If not, not splitting it is the best solution by definition. As
this should be a very common case in normal code, not exploring the entire
solution space can provide significant speedup.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@170457 91177308-0d34-0410-b5e6-96231b3b80d8
avoided.
This required a minor modification of the memoization as now the
"CurrentPenalty" depends on whether or not we break before the current
token. Therefore, the CurrentPenalty should not be memoized but added
after retrieving a value from memory. This should not affect the runtime
behavior.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@170337 91177308-0d34-0410-b5e6-96231b3b80d8
More specifically:
- Improve formatting of static initializers.
- Fix formatting of lines comments in enums.
- Fix formmating of trailing line comments.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@170316 91177308-0d34-0410-b5e6-96231b3b80d8
- Fix behavior of memoization together with optimization
- Correctly attribute the PenaltyIndentLevel (breaking directly after "(" did
not count towards the inner level)
- Recognize more tokens as assignments
Review: http://llvm-reviews.chandlerc.com/D172
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169384 91177308-0d34-0410-b5e6-96231b3b80d8
Recognize '!=' as a binary operator and assume that there are no
type definitions on the RHS of an assignment.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169363 91177308-0d34-0410-b5e6-96231b3b80d8
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169237 91177308-0d34-0410-b5e6-96231b3b80d8
The necessity of this fix points to a problem with the design
of the addToken during the optimiation phase, which we need to address
in a much more principled way.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169151 91177308-0d34-0410-b5e6-96231b3b80d8
Manuel Klimek