init list formatting. This suggestion has now gone into the LLVM coding
standards, and is particularly relevant now that we're using C++11.
Updated a really ridiculous number of tests to reflect this change.
llvm-svn: 202637
Before:
auto result = SomeObject
// Calling someFunction on SomeObject
.someFunction();
After:
auto result = SomeObject
// Calling someFunction on SomeObject
.someFunction();
llvm-svn: 201138
Mozilla and WebKit seem to use a space after @property (verified by
grepping their codebases) so we turn this on there as well.
Change by Christian Legnitto. Thank you!
llvm-svn: 200320
encodes the canonical rules for LLVM's style. I noticed this had drifted
quite a bit when cleaning up LLVM, so wanted to clean up Clang as well.
llvm-svn: 198686
Unexpectedly, it seems that people commonly know what they were doing
when writing a comment.
Also, being more conservative about comment breaking has the advantage
of giving more flexibility. If a linebreak within the comment can
improve formatting, the author can add it (after which clang-format
won't undo it). There is no way to override clang-format's behavior if
it breaks a comment.
llvm-svn: 197698
Formatting this:
void f() { // 1 space initial indent.
int i;
#define A \
int i; \
int j;
int k; // Format this line.
}
void f() {
#define A 1 // Format this line.
}
Before:
void f() { // 1 space initial indent.
int i;
#define A \
int i; \
int j;
int k; // Format this line.
}
void f() {
#define A 1 // Format this line.
}
After:
void f() { // 1 space initial indent.
int i;
#define A \
int i; \
int j;
int k; // Format this line.
}
void f() {
#define A 1 // Format this line.
}
llvm-svn: 197494
BreakConstructorInitializersBeforeComma is true.
This option is used in WebKit style, so this also ensures initializer lists are
not put on a single line, as per the WebKit coding guidelines.
Patch by Florian Sowade!
llvm-svn: 197386
Summary:
Added BraceBreakingStyle::BS_GNU. I'm not sure about the correctness of
static initializer formatting, but compound statements should be fine.
Reviewers: djasper
Reviewed By: djasper
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D2372
llvm-svn: 197138
Summary:
This still misses a few important features, so there's no mention of
this style in the help message, but a few style rules are implemented.
Reviewers: djasper
Reviewed By: djasper
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D2371
llvm-svn: 196928
Summary:
Allow predefined styles to define different options for different
languages so that one can run:
clang-format -style=google file1.cpp file2.js
or use a single .clang-format file with "BasedOnStyle: Google" for both c++ and
JS files.
Added Google style for JavaScript with "BreakBeforeTernaryOperators" set to
false.
Reviewers: djasper
Reviewed By: djasper
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D2364
llvm-svn: 196909
Summary:
The rule from the GNU style states:
"We find it easier to read a program when it has spaces before the open-parentheses and after the commas."
http://www.gnu.org/prep/standards/standards.html#index-spaces-before-open_002dparen
This patch makes clang-format adds an option to put spaces before almost all open parentheses, except the cases, where different behavior is dictated by the style rules or language syntax:
* preprocessor:
** function-like macro definitions can't have a space between the macro name and the parenthesis;
** `#if defined(...)` can have a space, but it seems, that it's more frequently used without a space in GCC, for example;
* never add spaces after unary operators;
* adding spaces between two opening parentheses is controlled with the `SpacesInParentheses` option;
* never add spaces between `[` and `(` (there's no option yet).
Reviewers: djasper
Reviewed By: djasper
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D2326
llvm-svn: 196901
Summary:
Allow tryFitMultipleLinesInOne join unwrapped lines when
ContinuationIndenter::mustBreak doesn't agree. But don't merge any lines, that
are separate in the input.
Reviewers: djasper
Reviewed By: djasper
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D2321
llvm-svn: 196378
Before:
int aaaa; // This line is formatted.
// The comment continues ..
// .. here.
Before:
int aaaa; // This line is formatted.
// The comment continues ..
// .. here.
This fixes llvm.org/PR17914.
llvm-svn: 195954
Previously, clang-format could create quite corrupt formattings if
individual lines of nested blocks (e.g. in "DEBUG({})" or lambdas) were
used. With this patch, it tries to extend the formatted regions to leave
around some reasonable format without always formatting the entire
surrounding statement.
llvm-svn: 195925
No functional changes intended. However, it seems to have found a buggy
behavior in one of the tests. I think this structure is generally
desirable and it will make a planned bugfix significantly easier.
llvm-svn: 195634
Summary:
Now based on token merging. Now they are not only prevented from being
split, but are actually formatted as comparison operators.
Reviewers: djasper, klimek
Reviewed By: klimek
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D2240
llvm-svn: 195354
Summary:
The AllowShortFunctionsOnASingleLine option now controls short function
body placement on a single line independent of the BreakBeforeBraces option.
Updated tests using BreakBeforeBraces other than BS_Attach.
Addresses http://llvm.org/PR17888
Reviewers: klimek, djasper
Reviewed By: klimek
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D2230
llvm-svn: 195256
Before, clang-format would always format entire nested blocks, which
can be unwanted e.g. for long DEBUG({...}) statements. Also
clang-format would not allow to merge lines in nested blocks (e.g. to
put "if (a) return;" on one line in Google style).
This is the first step of several refactorings mostly focussing on the
additional functionality (by reusing the "format many lines" code to
format the children of a nested block). The next steps are:
* Pull out the line merging into its own class.
* Seperate the formatting of many lines from the formatting of a single
line (and the analysis of the solution space).
llvm-svn: 194090
Same as SpacesInParentheses, this option allows adding a space inside
the '<' and '>' of a template parameter list.
Patch by Christopher Olsen.
This fixes llvm.org/PR17301.
llvm-svn: 193614
Specifically make clang-format less eager to break after the opening
parenthesis of a function call.
Before:
aaaaaaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa + aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
After:
aaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa +
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
Apparently that is preferable. This penalties are adapted
conservatively, we might have to increase them a little bit further.
llvm-svn: 193410
Before:
DEBUG({ // Comment that used to confuse clang-format.
fdafas();
});
Before:
DEBUG({ // Comments are now fine.
fdafas();
});
This fixed llvm.org/PR17619.
llvm-svn: 193051
Before, clang-format would not adjust leading indents if it found a
structural error (e.g. unmatched {}). It seems, however, that
clang-format has gotten good enough at parsing the code structure that
this hurts in almost all cases. Commonly, while writing code, it is
very useful to be able to correclty indent incomplete if statements or
for loops.
In case this leads to errors that we don't anticipate, we need to find
out and fix those.
This fixed llvm.org/PR17594.
llvm-svn: 192988
Summary:
Store IndentationLevel in ParentState and use it instead of the
Line::Level when indening.
Also fixed incorrect indentation level calculation in formatFirstToken.
Reviewers: djasper
Reviewed By: djasper
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D1797
llvm-svn: 192563
In certain macros or incorrect string literals, the token stream can
contain 'unknown' tokens, e.g. a single backslash or a set of empty
ticks. clang-format simply treated them as whitespace and removed them
prior to this patch.
This fixes llvm.org/PR17215
llvm-svn: 192490
The help text for clang-format's -style option and the function that processes
its value is moved to libFormat in this patch. The goal is to enable other
tools that use libFormat and also have a -style option to behave consistently
with clang-format.
llvm-svn: 191666
Summary:
Changed UseTab to be a enum with three options: Never, Always,
ForIndentation (true/false are still supported when reading .clang-format).
IndentLevel should currently be propagated correctly for all tokens, except for
block comments. Please take a look at the general idea before I start dealing
with block comments.
Reviewers: klimek, djasper
Reviewed By: klimek
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1770
llvm-svn: 191527
Summary:
reformat() tries to determine the newline style used in the input
(either LF or CR LF), and uses it for the output. Maybe not every single case is
supported, but at least the bug described in http://llvm.org/PR17182 should be
resolved.
Reviewers: djasper
Reviewed By: djasper
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D1643
llvm-svn: 190519
Summary: This also unifies the handling of escaped newlines for all tokens.
Reviewers: djasper
Reviewed By: djasper
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D1638
llvm-svn: 190405
Summary:
This fixes various issues with mixed tabs and spaces handling, e.g.
when realigning block comments.
Reviewers: klimek, djasper
Reviewed By: djasper
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1608
llvm-svn: 190395
Let clang-format consistently keep up to one empty line (configured via
FormatStyle::MaxEmptyLinesToKeep) in nested blocks, e.g. lambdas. Also,
actually format single statements in nested blocks.
Before:
DEBUG({ int i; });
DEBUG({
int i;
// an empty line here would just be removed.
int j;
});
After:
DEBUG({ int i; });
DEBUG({
int i;
int j;
});
llvm-svn: 190278
Before:
FirstToken->WhitespaceRange.getBegin()
.getLocWithOffset(First->LastNewlineOffset);
After:
FirstToken->WhitespaceRange.getBegin().getLocWithOffset(
First->LastNewlineOffset);
Re-add logic to prevent breaking after an empty set of parentheses.
Basically it seems that calling a function without parameters is more
like navigating along the same object than it is a separate step of a
builder-type call.
We might need to extends this in future to allow "short" parameters that
e.g. are an index accessing a specific element.
llvm-svn: 190126
This fixes two issues:
1) The indent of a line comment was not adapted to the subsequent
statement as it would be outside of a nested block.
2) A missing DryRun flag caused actualy breaks to be inserted in
overly long comments while trying to come up with the best line
breaking decisions.
llvm-svn: 190123
Summary:
Count column width instead of the number of code points. This also
includes correct handling of tabs inside string literals and comments (with an
exception of multiline string literals/comments, where tabs are present before
the first escaped newline).
Reviewers: djasper, klimek
Reviewed By: klimek
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D1601
llvm-svn: 190052
Summary:
Store first and last newline position in the token text for string literals and
comments to avoid doing .find('\n') for each possible solution.
Reviewers: djasper
Reviewed By: djasper
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D1556
llvm-svn: 189758
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
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
Goals: Structure code better and make components easier to use for
future features (e.g. column layout for long braced initializers).
No functional changes intended.
llvm-svn: 188543
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
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
Before, clang-format would not break overly long string literals
following a "<<" with FormatStyle::AlwaysBreakBeforeMultilineStrings
being set.
llvm-svn: 187650
Before:
template <bool B, bool C>
class A {
static_assert(B &&C, "Something is wrong");
};
After:
template <bool B, bool C>
class A {
static_assert(B && C, "Something is wrong");
};
(Note the spacing around '&&'). Also change the identifier table to always
understand all C++11 keywords (which seems like the right thing to do).
llvm-svn: 187589
With this patch, clang-format can be configured to:
* not indent in namespace at all (former behavior).
* indent in namespace as in other blocks.
* indent only in inner namespaces (as required by WebKit style).
Also fix alignment of access specifiers in WebKit style.
Patch started by Marek Kurdej. Thank you!
llvm-svn: 187540
New options:
* Break before the commas of constructor initializers and align
the commas with the colon.
* Break before binary operators
Additionally, for styles without column limit, don't just accept
linebreaks done by the user, but instead remove 'invalid' (according
to the current style) linebreaks and add 'required' ones.
llvm-svn: 187210
This is far from implementing all the rules given by
http://www.webkit.org/coding/coding-style.html
The important new feature is the support for styles that don't have a
column limit. For such styles, clang-format will (at the moment) simply
respect the input's formatting decisions within statements.
llvm-svn: 187033
The AlwaysBreakBeforeMultilineStrings rule does not really make sense
if it does not a column gain.
Before (in Google style):
f(
"aaaa"
"bbbb");
After:
f("aaaa"
"bbbb");
llvm-svn: 186515
Motivating example:
// column limit ------------------->
void ffffffffffff(int aaaaaa /* test */);
Formatting before the patch:
void ffffffffffff(int aaaaaa /* test
*/);
Formatting after the patch:
void
ffffffffffff(int aaaaaa /* test */);
llvm-svn: 186471
Summary:
These can appear when comments contain command lines with quoted line
breaks. As the text (including escaped newlines and '//' from consecutive lines)
is a single line comment, we used to break it even when it didn't exceed column
limit. This is a temporary solution, in the future we may want to support this
case completely - at least adjust leading whitespace when changing indentation
of the first line.
Reviewers: djasper
Reviewed By: djasper
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D1146
llvm-svn: 186456
The fundamental concept is:
Format as if the braced init list was a function call (with parentheses
replaced by braces). If there is no name/type before the opening brace
(e.g. if the braced list is nested), assume a zero-length identifier
just before the opening brace.
This behavior is gated on a new style flag, which for now replaces the
SpacesInBracedLists style flag. Activate this style flag for Google
style to reflect recent style guide changes.
llvm-svn: 186433
Daniel Jasper