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
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.
llvm-svn: 172200
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.
llvm-svn: 172196
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
llvm-svn: 172140
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).
llvm-svn: 172110
Don't do this in Google style though:
http://google-styleguide.googlecode.com/svn/trunk/objcguide.xml#Protocols
Most other places (function declarations, variable declarations) still get
this wrong, and since this looks very similiar to template instantiations to
the lexer (`id <MyProtocol> a = ...`), it's going to be hard to fix in some
places.
llvm-svn: 172099
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.
llvm-svn: 172093
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)
};
llvm-svn: 172076
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.
llvm-svn: 172070
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.
llvm-svn: 172065
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 };
llvm-svn: 172058
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.
llvm-svn: 172056
Just reuse the @interface code for this. It accepts slightly more than
necessary (@implementation cannot have protocol lists), but that's ok.
llvm-svn: 172019
