Summary:
Detect if the file is valid UTF-8, and if this is the case, count code
points instead of just using number of bytes in all (hopefully) places, where
number of columns is needed. In particular, use the new
FormatToken.CodePointCount instead of TokenLength where appropriate.
Changed BreakableToken implementations to respect utf-8 character boundaries
when in utf-8 mode.
Reviewers: klimek, djasper
Reviewed By: djasper
CC: cfe-commits, rsmith, gribozavr
Differential Revision: http://llvm-reviews.chandlerc.com/D918
llvm-svn: 183312
Gets rid of AnnotatedToken, putting everything into FormatToken.
FormatTokens are created once, and only referenced by pointer. This
enables multiple future features, like having tokens shared between
multiple UnwrappedLines (while there's still work to do to fully enable
that).
llvm-svn: 182859
With option enabled (e.g. in Google-style):
template <typename T>
void f() {}
With option disabled:
template <typename T> void f() {}
Enabling this for Google-style and Chromium-style, not sure which other
styles would prefer that.
llvm-svn: 182849
Before:
int (*func)(void*);
void f() { int(*func)(void*); }
After (consistent space after "int"):
int (*func)(void*);
void f() { int (*func)(void*); }
llvm-svn: 182756
Before:
@{ NSFontAttributeNameeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
: regularFont, };
Now:
@{ NSFontAttributeNameeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee :
regularFont, };
':'s in dictionary literals (and the corresponding {}s) are now marked as
TT_ObjCDictLiteral too, which makes further improvements to dict literal
layout possible.
llvm-svn: 182716
Before:
vector<int> x { 1, 2, 3 };
After:
vector<int> x{ 1, 2, 3 };
Also add a style option to remove the spaces inside braced lists,
so that the above becomes:
std::vector<int> v{1, 2, 3};
llvm-svn: 182570
Instead of selectively storing some changes and directly generating
replacements for others, we now notify the WhitespaceManager of the
whitespace before every token (and optionally with more changes inside
tokens).
Then, we run over all whitespace in the very end in original source
order, where we have all information available to correctly align
comments and escaped newlines.
The future direction is to pull more of the comment alignment
implementation that is now in the BreakableToken into the
WhitespaceManager.
This fixes a bug when aligning comments or escaped newlines in unwrapped
lines that are handled out of order:
#define A \
f({ \
g(); \
});
... now gets correctly layouted.
llvm-svn: 182467
clang-format was a bit too aggressive when trying to keep labels and
values on the same line.
Before:
llvm::outs()
<< "aaaaaaaaaaaaaaaaaaa: " << aaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaaaaaaaaaa);
After:
llvm::outs() << "aaaaaaaaaaaaaaaaaaa: "
<< aaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaaaaaaa);
llvm-svn: 182458
If clang-format is confronted with long and deeply nested lines (e.g.
complex static initializers or function calls), it can currently try too
hard to find the optimal solution and never finish. The reason is that
the memoization does not work effectively for deeply nested lines.
This patch removes an earlier workaround and instead opts for
accepting a non-optimal solution in rare cases. However, it only does
so only in cases where it would have to analyze an excessive number of
states (currently set to 10000 - the most complex line in Format.cpp
requires ~800 states) so this should not change the behavior in a
relevant way.
llvm-svn: 182449
The function type detection in r181438 and r181764 detected function
types too eagerly. This led to inconsistent formatting of inline
assembly and (together with r181687) to an incorrect formatting of calls
in macros.
Before: #define DEREF_AND_CALL_F(parameter) f (*parameter)
After: #define DEREF_AND_CALL_F(parameter) f(*parameter)
llvm-svn: 181870
This seems to be the vastly more common case. If we find enough
examples to the contrary, we can make it smarter.
Before: #define MACRO void f(int * a)
After: #define MACRO void f(int *a)
llvm-svn: 181687
Before, the actual operator of an overloaded operator declaration was
handled as a binary operator an thus, clang-format could not find valid
formattings for many examples, e.g.:
template <typename AAAAAAA, typename BBBBBBB>
AAAAAAA operator/(const AAAAAAA &a, BBBBBBB &b);
llvm-svn: 181585
With style where the *s go with the type:
Before: typedef bool* (Class:: *Member)() const;
After: typedef bool* (Class::*Member)() const;
llvm-svn: 181439
If the LHS of a binary expression is broken, clang-format should also
break after the operator as otherwise:
- The RHS can be easy to miss
- It can look as if clang-format doesn't understand operator precedence
Before:
bool aaaaaaaaaaaaaaaaaaaaa = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa !=
bbbbbbbbbbbbbbbbbb && ccccccccc == ddddddddddd;
After:
bool aaaaaaaaaaaaaaaaaaaaa =
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa != bbbbbbbbbbbbbbbbbb &&
ccccccccc == ddddddddddd;
As an additional note, clang-format would also be ok with the following
formatting, it just has a higher penalty (IMO correctly so).
bool aaaaaaaaaaaaaaaaaaaaa = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa !=
bbbbbbbbbbbbbbbbbb &&
ccccccccc == ddddddddddd;
llvm-svn: 181430
clang-format did not indent any declarations/definitions when breaking
after the type. With this change, it indents for all declarations but
does not indent for function definitions, i.e.:
Before:
const SomeLongTypeName&
some_long_variable_name;
typedef SomeLongTypeName
SomeLongTypeAlias;
const SomeLongReturnType*
SomeLongFunctionName();
const SomeLongReturnType*
SomeLongFunctionName() { ... }
After:
const SomeLongTypeName&
some_long_variable_name;
typedef SomeLongTypeName
SomeLongTypeAlias;
const SomeLongReturnType*
SomeLongFunctionName();
const SomeLongReturnType*
SomeLongFunctionName() { ... }
While it might seem inconsistent to indent function declarations, but
not definitions, there are two reasons for that:
- Function declarations are very similar to declarations of function
type variables, so there is another side to consistency to consider.
- There can be many function declarations on subsequent lines and not
indenting can make them harder to identify. Function definitions
are already separated by their body and not indenting
makes the function name slighly easier to find.
llvm-svn: 181187
This seems to be more common in LLVM, Google and Chromium.
Before:
class AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA :
public BBBBBBBBBBBBBBBBBBBBBBBBBBBBBB,
public CCCCCCCCCCCCCCCCCCCCCCCCCCCCCC {
};
After:
class AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
: public BBBBBBBBBBBBBBBBBBBBBBBBBBBBBB,
public CCCCCCCCCCCCCCCCCCCCCCCCCCCCCC {
};
llvm-svn: 181183
Deeply nested expressions basically break clang-format's memoization.
This patch slightly improves the situations and makes expressions like
aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(
aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(
aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(
aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(aaaaa(
aaaaa(aaaaa())))))))))))))))))))))))))))))))))))))));
work.
llvm-svn: 180264
Function declarations are now broken with the following preferences:
1) break amongst arguments.
2) break after return type.
3) break after (.
4) break before after nested name specifiers.
Options #2 or #3 are preferred over #1 only if a substantial number of
lines can be saved by that.
llvm-svn: 179287
Before:
class A {
public : // test
};
After:
class A {
public: // test
};
Also remove duplicate methods calculating properties of AnnotatedTokens
and make them members of AnnotatedTokens so that they are in a common
place.
llvm-svn: 179167
The idea is to indent according to operator precedence and pretty much
identical to how stuff would be indented with parenthesis.
Before:
bool value = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa +
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa +
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ==
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa *
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb +
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb &&
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa *
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa >
ccccccccccccccccccccccccccccccccccccccccc;
After:
bool value = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa +
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa +
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ==
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa *
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb +
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb &&
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa *
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa >
ccccccccccccccccccccccccccccccccccccccccc;
llvm-svn: 179049
This combines several related changes:
a) Don't break before after the variable types in for loops with a
single variable.
b) Better indent DeclStmts defining multiple variables.
Before:
bool aaaaaaaaaaaaaaaaaaaaaaaaa =
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaa),
bbbbbbbbbbbbbbbbbbbbbbbbb =
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb(bbbbbbbbbbbbbbbb);
for (aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaa = aaaaaaaaaaaaaaaa.aaaaaaaaaaaaaaa;
aaaaaaaaaaa != aaaaaaaaaaaaaaaaaaa; ++aaaaaaaaaaa) {
}
After:
bool aaaaaaaaaaaaaaaaaaaaaaaaa =
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaa),
bbbbbbbbbbbbbbbbbbbbbbbbb =
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb(bbbbbbbbbbbbbbbb);
for (aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaa =
aaaaaaaaaaaaaaaa.aaaaaaaaaaaaaaa;
aaaaaaaaaaa != aaaaaaaaaaaaaaaaaaa; ++aaaaaaaaaaa) {
}
llvm-svn: 178641
It turns out that
-foo;
can be an objective C method declaration. So instead of the previous
solution, recognize objective C methods only if we are in a declaration
scope.
llvm-svn: 177740
Summary: Added support for pointers-to-members usage via .* and a few tests.
Reviewers: djasper
Reviewed By: djasper
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D556
llvm-svn: 177537
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Daniel Jasper