| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
|
| |
MS cl.exe is unaware of BOM-less utf8 source files.
FIXME: Encode Cyrillic and CJK characters below to appease MS compilers.
llvm-svn: 183366
|
| |
|
|
| |
llvm-svn: 183315
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These lines almost never aid readability.
Before:
void f() {
int i; // some variable
}
After:
void f() {
int i; // some variable
}
llvm-svn: 183112
|
| |
|
|
|
|
|
|
|
|
| |
An oversight in this detection made clang-format unable to format
the following nicely:
void aaaaaaaaaaaaaaaaaaa<aaaaaaaaaaaaaaaaaaaaaaaaaaa,
bbbbbbbbbbbbbbbbbbbbbbbbbb>(
cccccccccccccccccccccccccccc);
llvm-svn: 183097
|
| |
|
|
|
|
|
|
|
|
| |
Before, clang-format would not find a solution for formatting:
if ((aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ||
bbbbbbbbbbbbbbbbbb) && // aaaaaaaaaaaaaaaa
cccccc) {
}
llvm-svn: 183096
|
| |
|
|
|
|
| |
Before: return a<b &&c> d;
After: return a < b && c > d;
llvm-svn: 183077
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
x[(uint8) y];
x = (uint8) y;
void f() { x = (uint8) y; }
#define AA(X) sizeof(((X *) NULL)->a)
After:
x[(uint8)y];
x = (uint8)y;
void f() { x = (uint8)y; }
#define AA(X) sizeof(((X *)NULL)->a)
llvm-svn: 183014
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
If a "}" is found inside parenthesis, this is probably a case of
missing parenthesis. This enables continuing to format after stuff code
like:
class A {
void f(
};
..
llvm-svn: 183009
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this patch, the simplified rule is:
If the block is part of a declaration (class, namespace, function,
enum, ..), merge an empty block onto a single line. Otherwise
(specifically for the compound statements of if, for, while, ...),
keep the braces on two separate lines.
The reasons are:
- Mostly the formatting of empty blocks does not matter much.
- Empty compound statements are really rare and are usually just
inserted while still working on the code. If they are on two lines,
inserting code is easier. Also, overlooking the "{}" of an
"if (...) {}" can be really bad.
- Empty declarations are not uncommon, e.g. empty constructors. Putting
them on one line saves vertical space at no loss of readability.
llvm-svn: 183008
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
bool aaaaaa = aaaaaaaaaaaaa //
? aaaaaaaaaaaaaaa
: bbbbbbbbbbbbbbb //
? ccccccccccccccc
: ddddddddddddddd;
After:
bool aaaaaa = aaaaaaaaaaaaa //
? aaaaaaaaaaaaaaa
: bbbbbbbbbbbbbbb //
? ccccccccccccccc
: ddddddddddddddd;
llvm-svn: 183007
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
foo = aaaaaaaaaaa ? vector<int> {
aaaaaaaaaaaaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaa, aaaaa
}
: vector<int>{ bbbbbbbbbbbbbbbbbbbbbbbbbbb, bbbbbbbbbbbbbbbbbbbb, bbbbb };
After:
foo = aaaaaaaaaaa ? vector<int>{ aaaaaaaaaaaaaaaaaaaaaaaaaaa,
aaaaaaaaaaaaaaaaaaaa, aaaaa }
: vector<int>{ bbbbbbbbbbbbbbbbbbbbbbbbbbb,
bbbbbbbbbbbbbbbbbbbb, bbbbb };
llvm-svn: 182992
|
| |
|
|
| |
llvm-svn: 182940
|
| |
|
|
|
|
|
|
|
|
| |
This fixes:
/*
*
* something long going over the column limit.
*/
llvm-svn: 182932
|
| |
|
|
|
|
|
|
|
| |
Smallest reproduction:
/*
**
*/
llvm-svn: 182913
|
| |
|
|
|
|
|
|
| |
When trying to fall back to search from the end onwards, we
would still find leading whitespace if the leading whitespace
went on after the end of the line.
llvm-svn: 182886
|
| |
|
|
| |
llvm-svn: 182856
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If an identifier is on its own line and it is all upper case, it is highly
likely that this is a macro that is meant to stand on a line by itself.
Before:
class A : public QObject {
Q_OBJECT A() {}
};
Ater:
class A : public QObject {
Q_OBJECT
A() {}
};
llvm-svn: 182855
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This made it necessary to remove an error detection which would let us
bail out of braced lists in certain situations of missing "}". However,
as we always entirely escape from the braced list on finding ";", this
should not be a big problem.
With this, we can no format braced lists with uniformat inits:
return { arg1, SomeType { parameter } };
llvm-svn: 182788
|
| |
|
|
|
|
|
|
|
| |
Before: f( (*PointerToArray)[10]);
After: f((*PointerToArray)[10]);
This fixes llvm.org/PR16163
llvm-svn: 182777
|
| |
|
|
| |
llvm-svn: 182767
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To fully support this, we also need to expand tabs in the text before
the block comment. This patch breaks indentation when there was a
non-standard mixture of spaces and tabs used for indentation, but
fixes a regression in the simple case:
{
/*
* Comment.
*/
int i;
}
Is now formatted correctly, if there were tabs used for indentation
before.
llvm-svn: 182760
|
| |
|
|
|
|
|
|
|
|
|
| |
Block comment indentation of empty lines regressed, as we did not
have a test for it.
/* Comment with...
*
* empty line. */
is now formatted correctly again.
llvm-svn: 182757
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This gets turned into two ">" operators at the beginning in order to
simplify template parameter handling. Thus, we need a special case to
handle those two binary operators correctly.
With this patch, clang-format can now correctly handle cases like:
aaaaaa = aaaaaaa(aaaaaaa, // break
aaaaaa) >>
bbbbbb;
llvm-svn: 182754
|
| |
|
|
|
|
|
|
|
| |
Before: A < int&& > a;
After: A<int &&> a;
Also remove obsolete FIXMEs.
llvm-svn: 182741
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unify handling of whitespace when breaking protruding tokens with other
whitespace replacements.
As a side effect, the BreakableToken structure changed significantly:
- have a common base class for single-line breakable tokens, as they are
much more similar
- revamp handling of multi-line comments; we now calculate the
information about lines in multi-line comments similar to normal
tokens, and always issue replacements
As a result, we were able to get rid of special casing of trailing
whitespace deletion for comments in the whitespace manager and the
BreakableToken and fixed bugs related to tab handling and escaped
newlines.
llvm-svn: 182738
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
unsigned OriginalStartColumn = SourceMgr.getSpellingColumnNumber(
Current.FormatTok.getStartOfNonWhitespace()) -
1;
After:
unsigned OriginalStartColumn =
SourceMgr.getSpellingColumnNumber(
Current.FormatTok.getStartOfNonWhitespace()) -
1;
llvm-svn: 182733
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In general, we like to avoid line breaks like:
...
SomeParameter, OtherParameter).DoSomething(
...
as they tend to make code really hard to read (how would you even indent the
next line?). Previously we have implemented this in a hacky way, which has now
shown to lead to problems. This fixes a few weird looking formattings, such as:
Before:
aaaaa(
aaaaa(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa)
.aaaaa(aaaaa),
aaaaaaaaaaaaaaaaaaaaa);
After:
aaaaa(aaaaa(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa).aaaaa(aaaaa),
aaaaaaaaaaaaaaaaaaaaa);
llvm-svn: 182731
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Added stack of preprocessor branching directives, and ignore all tokens
inside #if 0 except for preprocessor directives.
Reviewers: klimek, djasper
Reviewed By: klimek
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D855
llvm-svn: 182658
|
| |
|
|
|
|
| |
Before: f(new vector<int> { 1, 2, 3 });
After: f(new vector<int>{ 1, 2, 3 });
llvm-svn: 182614
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we started sequences to align for single line comments when
the previous line had a trailing comment, but the sequence was broken
for other reasons.
Now we re-format:
// a
// b
f(); // c
to:
// a
// b
f(); // c
llvm-svn: 182608
|
| |
|
|
|
|
|
|
|
|
| |
Now correctly leaves:
f(); // comment
// comment
g(); // comment
... alone if the middle comment was aligned with g() before formatting.
llvm-svn: 182605
|
| |
|
|
|
|
| |
Also fix a minor bug for constructor initializers with braced init lists.
llvm-svn: 182601
|
| |
|
|
|
|
| |
Before: vector<int> v{ -1};
After: vector<int> v{-1};
llvm-svn: 182597
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we would align:
f(); // comment
// other comment
g();
Even if // other comment was at the start of the line. Now we do not
align trailing comments if they have been already aligned correctly
with the next line.
Thus,
f(); // comment
// other comment
g();
will not be changed, while:
f(); // comment
// other commment
g();
will lead to the two trailing comments being aligned.
llvm-svn: 182577
|
| |
|
|
|
|
|
|
|
|
|
| |
Replaces the use of WhitespaceStart + WhitspaceLength.
This made a bug in the formatter obvous where we would incorrectly
calculate the next column.
FIXME: There's a similar bug left regarding TokenLength. We should
probably also move to have a TokenRange instead.
llvm-svn: 182572
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allows formatting of C++11 braced init list constructs, like:
vector<int> v { 1, 2, 3 };
f({ 1, 2 });
This involves some changes of how tokens are handled in the
UnwrappedLineFormatter. Note that we have a plan to evolve the
design of the token flow into one where we create all tokens
up-front and then annotate them in the various layers (as we
currently already have to create all tokens at once anyway, the
current abstraction does not help). Thus, this introduces
FIXMEs towards that goal.
llvm-svn: 182568
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This only affects styles that prevent bin packing. There, a break after
a template declaration also forced a line break after the function name.
Before:
template <class SomeType, class SomeOtherType>
SomeType
SomeFunction(SomeType Type, SomeOtherType OtherType) {}
After:
template <class SomeType, class SomeOtherType>
SomeType SomeFunction(SomeType Type, SomeOtherType OtherType) {}
This fixes llvm.org/PR16072.
llvm-svn: 182457
|
| |
|
|
|
|
|
| |
Reduce the preference for breaking before a trailing 'const' according
to review comments on r182362.
llvm-svn: 182455
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
void someLongFunction(
int someLongParameter) const;
After:
void someLongFunction(int someLongParameter)
const;
Also slightly cleanup tests.
llvm-svn: 182362
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: + improved handling of default style and predefined styles.
Reviewers: djasper, klimek
Reviewed By: klimek
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D813
llvm-svn: 182205
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Basically, the new rule is: The opening "{" always has to be on the
same line as the first element if the braced list is nested
(e.g. in another braced list or in a function).
The solution that clang-format produces almost always adheres to this
rule anyway and this makes clang-format significantly faster for larger
lists. Added a test cases for the only exception I could find
(which doesn't seem to be very important at first sight).
llvm-svn: 182082
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This ensures that we format:
void longFunctionName {
} // long comment here
And not:
void longFunctionName {}
// long comment here
As requested in post-commit-review.
llvm-svn: 182024
|
