This patch makes sure we produce the right number of unwrapped lines,
a follow-up patch will make the whitespace formatting consistent.
Before:
void f() {
int i = {[operation setCompletionBlock : ^{ [self onOperationDone];
}]
}
;
}
After:
void f() {
int i = {[operation setCompletionBlock : ^{
[self onOperationDone];
}] };
}
llvm-svn: 189932
Implements parsing of lambdas in the UnwrappedLineParser.
This introduces the correct line breaks; the formatting of
lambda captures are still incorrect, and the braces are also
still formatted as if they were braced init lists instead of
blocks.
llvm-svn: 189818
Almost by accident, clang-format seems to be able to format protocol
buffer definitions (https://code.google.com/p/protobuf/).
The only change is that a space is required between numeric constants
and opening square brackets (for default values). While this might in
theory be used for array subscripts (int val = 4[MyArray]), I have not
seen this pattern in practice much. If this is wrong, we can make this
smarter in the future.
llvm-svn: 189663
Before:
aaaaaaaaaa(bbbbbbbbbbbbbbbbbbbbbbbbb.ccccccccccccccccc(
dddddddddddddddddddddddddddddd));
aaaaaaaaaaa(bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb(
dddddddddddddddddddddddddddddd));
After:
aaaaaaaaaaa(bbbbbbbbbbbbbbbbbbbbbbbbb.ccccccccccccccccc(
dddddddddddddddddddddddddddddd));
aaaaaaaaaaa(bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb(
dddddddddddddddddddddddddddddd));
This was overlooked when interducing the new builder-type call
detection in r189337. Also, some minor reorganization of a test.
llvm-svn: 189658
While this looks kind of nice, it wastes horizontal space and does not
seem to be common in the LLVM codebase.
Before:
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:
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);
llvm-svn: 189657
Summary:
Calculate characters in the first and the last line correctly so that
we only break before the literal when needed.
Reviewers: djasper
Reviewed By: djasper
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D1544
llvm-svn: 189595
We now count the original token's column directly when lexing the
tokens, where we already have all knowledge about where lines start.
Before this patch, formatting:
void f() {
\tg();
\th();
}
would incorrectly count the \t's as 1 character if only the line
containing h() was reformatted, and thus indent h() at offset 1.
llvm-svn: 189585
Two changes:
* Don't add an extra penalty on breaking the same token multiple times.
Generally, we should prefer not to break, but once we break, the
normal line breaking penalties apply.
* Slightly increase the penalty for breaking comments. In general, the
author has put some thought into how to break the comment and we
should not overwrite this unnecessarily.
With a 40-column column limit, formatting
aaaaaa("aaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaa");
Leads to:
Before:
aaaaaa(
"aaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaa "
"aaaaaaaaaaaaaaaa");
After:
aaaaaa("aaaaaaaaaaaaaaaa "
"aaaaaaaaaaaaaaaa "
"aaaaaaaaaaaaaaaa");
llvm-svn: 189466
The code leading to a segfault was:
#pragma omp threadprivate(y)), // long comment leading to a line break
This fixes llvm.org/PR16513.
llvm-svn: 189460
If escaped newlines are aligned right
(FormatStyle.AlignEscapedNewlinesLeft == false), and a line contained
too many characters to fit into the column limit, this would result in
a (virtually) endless loop creating a negative number of spaces.
Instead, allow the escaped newlines to be pushed past the column limit
in this case.
This fixes llvm.org/PR16515.
llvm-svn: 189459
In
@implementation ObjcClass
- (void)method;
{
}
@end
the ObjC compiler seems to accept the superfluous comma after "method",
but clang-format used to assert on the subsequent "{".
This fixes llvm.org/PR16604.
llvm-svn: 189453
Specific arrangements of comments after trailing commas could confuse
the column width calculation, e.g. in:
vector<int> x = { a, b,
/* some */ /* comment */ };
llvm-svn: 189211
This should be done, only if we are still in the unary expression's
scope.
Before:
bool aaaa = !aaaaaaaa( // break
aaaaaaaaaaa);
*aaaaaa = aaaaaaa( // break
aaaaaaaaaaaaaaaa);
After:
bool aaaa = !aaaaaaaa( // break
aaaaaaaaaaa); // <- (unchanged)
*aaaaaa = aaaaaaa( // break
aaaaaaaaaaaaaaaa); // <- (no longer indented relative to "*")
llvm-svn: 189108
.. in conjunction with Style.AlwaysBreakBeforeMultilineStrings. Also,
simplify the implementation by handling newly split strings and already
split strings by the same code.
llvm-svn: 189102
Before, this was causing errors.
Also exit early in breakProtrudingToken() (before the expensive call to
SourceManager::getSpellingColumnNumber()). This makes formatting huge
(100k+-item) braced lists possible.
llvm-svn: 189094
With this patch, braced lists (with more than 3 elements are formatted in a
column layout if possible). E.g.:
static const uint16_t CallerSavedRegs64Bit[] = {
X86::RAX, X86::RDX, X86::RCX, X86::RSI, X86::RDI,
X86::R8, X86::R9, X86::R10, X86::R11, 0
};
Required other changes:
- FormatTokens can now have a special role that contains extra data and can do
special formattings. A comma separated list is currently the only
implementation.
- Move penalty calculation entirely into ContinuationIndenter (there was a last
piece still in UnwrappedLineFormatter).
Review: http://llvm-reviews.chandlerc.com/D1457
llvm-svn: 189018
Before:
if (!aaaaaaaaaa( // break
aaaaa)) {
}
After:
if (!aaaaaaaaaa( // break
aaaaa)) {
}
Also cleaned up formatting using clang-format.
llvm-svn: 188891
This patch adds four new options to control:
- Spaces after control keyworks (if(..) vs if (..))
- Spaces in empty parentheses (f( ) vs f())
- Spaces in c-style casts (( int )1.0 vs (int)1.0)
- Spaces in other parentheses (f(a) vs f( a ))
Patch by Joe Hermaszewski. Thank you for working on this!
llvm-svn: 188793
Some coding styles use a different indent for constructor initializers.
Patch by Klemens Baum. Thank you.
Review: http://llvm-reviews.chandlerc.com/D1360
Post review changes: Changed data type to unsigned as a negative indent
width does not make sense and added test for configuration parsing.
llvm-svn: 188260
Previously these were formatting as catch (E & e) because the inner parenthesis
was being marked as an expression.
Patch by Thomas Gibson-Robinson.
llvm-svn: 188153
In particular, left braces after an enum declaration now occur on their
own line. Further, when short ifs/whiles are allowed these no longer
cause the left brace to be on the same line as the if/while when a
brace is included.
Patch by Thomas Gibson-Robinson.
llvm-svn: 187901
This removes a formatting choice that was added at one point, but is
not generally liked by users. Specifically, in builder-type calls, do
(easily) break if the object before the ./-> is either a field or a
parameter-less function call. I.e., don't break after "aa.aa.aa" or
"aa.aa.aa()". In general, these sequences in builder-type calls are
seen as a single entity and thus breaking them up is a bad idea.
llvm-svn: 187865
