Summary:
This fixes the missing space before the designated initializer when `Cpp11BracedListStyle=false` :
const struct A a = { .a = 1, .b = 2 };
^
Also, wrapping between opening brace and designated array initializers used to have an excessive penalty (like breaking between an expression and the subscript operator), leading to unexpected wrapping:
const struct Aaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaa =
{[1] = aaaaaaaaaaaaaaaaaaaaaaaaaaa,
[2] = bbbbbbbbbbbbbbbbbbbbbbbbbbb};
instead of:
const struct Aaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaa = {
[1] = aaaaaaaaaaaaaaaaaaaaaaaaaaa,
[2] = bbbbbbbbbbbbbbbbbbbbbbbbbbb};
Finally, designated array initializers are not binpacked, just like designated member initializers.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, krasimir, klimek
Differential Revision: https://reviews.llvm.org/D33491
llvm-svn: 305696
Fixes an issue where struct A { int X; }; would be broken onto multiple
lines, but typedef struct A { int X; } A2; was collapsed onto a single
line.
Patch by Jacob Bandes-Storch. Thank you.
llvm-svn: 305667
c++1z adds the following constructions to the language:
if constexpr (cond)
statement1;
else if constexpr (cond)
statement2;
else if constexpr (cond)
statement3;
else
statement4;
A first version of this was proposed in reviews.llvm.org/D26953 by
Francis Visoiu Mistrih, but never commited. This patch additionally
fixes the behavior when allowing short if statements on a single line
and was authored by Jacob Bandes-Storch. Thank you to both authors.
llvm-svn: 305666
Summary:
Add CompactNamespaces option, to pack namespace declarations on the
same line (somewhat similar to C++17 nested namespace definition).
With this option, consecutive namespace declarations are kept on the
same line:
namespace foo { namespace bar {
...
}} // namespace foo::bar
Reviewers: krasimir, djasper, klimek
Reviewed By: djasper
Subscribers: kimgr, cfe-commits, klimek
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D32480
llvm-svn: 305384
Summary:
This option supplements the AllowShortFunctionsOnASingleLine flag, to
merge empty function body at the beginning of the line: e.g. when the
function is not short-enough and breaking braces after function.
int f()
{}
Reviewers: krasimir, djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D33447
llvm-svn: 305272
Summary:
This patch is a follow-up of https://reviews.llvm.org/rL304687, which fixed an
overflow in the comment alignment code in clang-format. The token length of
trailing comments of preprocessor directives is calculated incorrectly by
including the text between consecutive directives. That causes them to not being
aligned.
For example, in this code with column limit 20
```
#if A
#else // A
int iiii;
#endif // B
```
the length of the token `// A` was wrongly calculated as 14 = 5 (the size of `// A\n`) plus 9 (the size of `int iiii;`) and so `// A` wouldn't be aligned with `// B` and this was produced:
```
#if A
#else // A
int iiii;
#endif // B
```
This patch fixes this case.
Reviewers: alexfh
Reviewed By: alexfh
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D33982
llvm-svn: 304912
Summary: Support "export type T = {...};", in addition to just "type T = {...};".
Reviewers: klimek
Differential Revision: https://reviews.llvm.org/D33980
llvm-svn: 304904
Nested literals are sometimes only indented by 2 spaces, instead of
respecting the IndentWidth option.
There are existing unit tests (FormatTestJS.ArrayLiterals) that only
pass because the style used to test them uses an IndentWidth of 2.
This change removes the magic 2 and always uses the IndentWidth.
I've added 6 tests. The first 4 of these tests fail before this change,
while the last 2 already pass, but were added just to make sure it the
change works with all types of braces.
Patch originally by Jared Neil, thanks!
Differential Revision: https://reviews.llvm.org/D33857
llvm-svn: 304791
Summary:
This patch fixes a bug where clang-format will align newly broken trailing
comments even if this will make them exceed the line limit. The bug was caused
by a combination of unsigned arithmetic overflow and an imprecise computation
of the length of broken comment lines.
Reviewers: djasper, alexfh
Reviewed By: alexfh
Subscribers: klimek
Differential Revision: https://reviews.llvm.org/D33830
llvm-svn: 304687
Summary:
calculateBraceTypes decides for braced init for empty brace pairs ({}).
In context of a function declaration, this incorrectly classifies empty
function or method bodies as braced inits, leading to missing wraps:
class C {
foo() {}[bar]() {}
}
Where code should have wrapped after "}", before "[". This change adds
another piece of contextual information in that braces following closing
parentheses must always be the opening braces of function blocks. This
fixes brace detection for methods immediately followed by brackets
(computed property declarations), but also curlies.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D33714
llvm-svn: 304290
Summary:
In JavaScript, duplicated commas have semantic meaning.
x = [a,,b];
The statement above creates an array with three entries, the middle being undefined. Because clang-format should not change semantics, disable this cleanup in JS.
Reviewers: djasper
Subscribers: klimek
Differential Revision: https://reviews.llvm.org/D33641
llvm-svn: 304141
Summary:
The previous fix to force build style wrapping if the previous token is a closing parenthesis broke a peculiar pattern where users parenthesize the function declaration in a bind call:
fn((function() { ... }).bind(this));
This restores the previous behaviour by reverting that change, but narrowing the special case for unindenting closing parentheses to those followed by semicolons and opening braces, i.e. immediate calls and function declarations.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D33640
llvm-svn: 304135
Summary:
This option replaces the BreakConstructorInitializersBeforeComma option with an enum, thus introducing a mode where the colon stays on the same line as constructor declaration:
// When it fits on line:
Constructor() : initializer1(), initializer2() {}
// When it does not fit:
Constructor() :
initializer1(), initializer2()
{}
// When ConstructorInitializerAllOnOneLineOrOnePerLine = true:
Constructor() :
initializer1(),
initializer2()
{}
Reviewers: krasimir, djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D32479
llvm-svn: 303739
The change that enabled wrapping at the previous scope's indentation had
unintended side-effects in that clang-format would prefer to wrap
closing parentheses to the next line if it avoided a wrap on the next
line (assuming very narrow lines):
fooObject
.someCall(barbazbam)
.then(bam);
Would get formatted as:
fooObject.someCall(barbazbam
).then(bam);
Because the ')' is now indented at the parent level (fooObject).
Normally formatting a builder pattern style call sequence like that is
outlawed in clang-format anyway. However for JavaScript this is special
cased to support trailing .bind calls.
This change disallows this special case when following a closing ')' to
avoid the problem.
Included are some random comment fixes.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D33399
llvm-svn: 303557
Summary:
This patch prevents reflowing bullet lists in block comments.
It handles all lists supported by doxygen and markdown, e.g. bullet
lists starting with '-', '*', '+', as well as numbered lists starting
with -# or a number followed by a dot.
Reviewers: krasimir
Reviewed By: krasimir
Subscribers: djasper, klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D33285
llvm-svn: 303556
Summary:
r303415 changed the way a sequence of line comments following a preprocessor
macro is handled, which has the unfortunate effect of aligning a trailing
preprocessor line comment and following unrelated section comments, so:
```
#ifdef A // comment about A
// section comment
#endif
```
gets turned into:
```
#ifdef A // comment about A
// section comment
#endif
```
This patch fixes this by additionally checking the original start columns of
the line comments.
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D33394
llvm-svn: 303541
Summary:
Add option to customize the penalty for breaking assignment
This allows increasing the priority of the assignment, to prefer spliting
an operation instead of splitting the assignment, e.g. :
int a = bbbbbbbbbbbbbbbb +
cccccccccccccccc;
Reviewers: krasimir, djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D32477
llvm-svn: 303534
Summary:
This patch updates the handling of multiline trailing comment sections in
import statement lines to make it more consistent with the case in general.
This includes updating the parsing logic to collect the trailing comment
sections and the formatting logic to not insert escaped newlines at the end of
comment lines in import statement lines.
Specifically, before this patch this code:
```
#include <a> // line 1
// line 2
```
will be turned into two unwrapped lines, whereas this code:
```
int i; // line 1
// line 2
```
is turned into a single unwrapped line, enabling reflowing across comments.
An example where the old behaviour is bad is when partially formatting the lines
3 to 4 of this code:
```
#include <a> // line 1
// line 2
int i;
```
which gets turned into:
```
#include <a> // line 1
// line 2
int i;
```
because the two comment lines were independent and the indent was copied.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D33351
llvm-svn: 303415
Summary:
The syntax is actually `for await (const x of y)` (d'oh).
This also fixes a crash for `for` tokens not followed by additional tokens.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D33329
llvm-svn: 303382
Summary:
Doxygen supports putting documentation blocks after member, by adding
an additional < marker in the comment block. This patch makes sure
this marker is used in lines which are introduced by breaking the
comment.
int foo; ///< Some very long comment.
becomes:
int foo; ///< Some very long
///< comment.
Contributed by @Typz!
Reviewers: krasimir
Reviewed By: krasimir
Subscribers: djasper, klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D33282
llvm-svn: 303330
myFunction(param1, param2,);
For symmetry with other parenthesized lists ([...], {...}), clang-format should
wrap parenthesized lists one-per-line if they contain a trailing comma:
myFunction(
param1,
param2,
);
This is particularly useful in function declarations or calls with many
arguments, e.g. commonly in constructors.
Differential Revision: https://reviews.llvm.org/D33023
llvm-svn: 303049
Summary:
`getIdentifierInfo()` includes all keywords, whereas non-null assertion
operators should only be recognized after non-keywords or pseudo keywords.
Ideally this should list all tokens that clang-format recognizes as a keyword,
but that are pseudo or no keywords in JS. For the time being, just recognize
the specific bits users ran into (`namespace` in this case).
Reviewers: djasper
Subscribers: klimek
Differential Revision: https://reviews.llvm.org/D33182
llvm-svn: 303038
Summary:
For C++ code, opening parenthesis following a } indicate a braced init. For JavaScript and other languages, this is an invalid syntactical construct, unless the closing parenthesis belongs to a function - in which situation its a BK_Block.
This fixes indenting IIFEs following top level functions:
function foo() {}
(function() { codeHere(); }());
clang-format used to collapse these lines together.
Subscribers: klimek
Differential Revision: https://reviews.llvm.org/D33006
llvm-svn: 302658
Because IIFEs[1] are often used like an anonymous namespace around large
sections of JavaScript code, it's useful not to indent to them (which
effectively reduces the column limit by the indent amount needlessly).
It's also common for developers to wrap these around entire files or
libraries. When adopting clang-format, changing the indent entire file
can reduce the usefulness of the blame annotations.
Patch by danbeam, thanks!
Differential Revision: https://reviews.llvm.org/D32989
llvm-svn: 302580
DontAlign
This converts the clang-format option AlignEscapedNewlinesLeft from a
boolean to an enum, named AlignEscapedNewlines, with options Left (prev.
true), Right (prev. false), and a new option DontAlign.
When set to DontAlign, the backslashes are placed just after the last token in each line:
#define EXAMPLE \
do { \
int x = aaaaa; \
int b; \
int dddddddddd; \
} while (0)
Patch by jtbandes. Thank you!
llvm-svn: 302428
Summary: While its precedence should be higher than multiplicative, LLVM does not have a level for that, so for the time being just treat it as multiplicative.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D32864
llvm-svn: 302156
Summary:
Previously, clang-format would accidentally parse an async function
declaration as a function expression, and thus not insert an unwrapped
line for async functions, causing subsequent functions to run into the
function:
async function f() {
x();
} function g() { ...
With this change, async functions get parsed as top level function
declarations and get their own unwrapped line context.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D32590
llvm-svn: 301538
Summary:
Java and JavaScript support annotations and decorators, respectively, that use a leading "@" token. clang-format currently detects this as an Objective-C construct and applies special formatting, for example no whitespace around "=" operators. This change disables the distinction for Java and JavaScript, which leads to normal formatting of single line annotated and initialized properties.
Before:
class X {
@foo() bar=false;
}
After:
class X {
@foo() bar = false;
}
Reviewers: djasper, bkramer
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D32532
llvm-svn: 301399
Summary: In JavaScript/TypeScript, class member definitions that use modifiers can be subject to Automatic Semicolon Insertion (ASI). For example, "class X { get \n foo }" defines a property called "get" and a property called "foo", both with no type annotation. This change prevents wrapping after the modifier keywords (visibility modifiers, static, get and set) to prevent accidental ASI.
Reviewers: djasper, bkramer
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D32531
llvm-svn: 301397
Before:
std::function<
LoooooooooooongTemplatedType<SomeType>*(
LooooooooooooooooooooongType
type)>
function;
After:
std::function<
LoooooooooooongTemplatedType<
SomeType>*(
LooooooooooooooooongType type)>
function;
clang-format generally avoids having lines like "SomeType>*(" as they
lead to parameter lists that don't belong together to be aligned. However, in
case it is better than the alternative, which can even be violating the column
limit.
llvm-svn: 301182
Summary: This patch replaces the boolean IncompleteFormat that is used to notify the client if an unrecoverable syntax error occurred by a struct that also contains a line number.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D32298
llvm-svn: 300985
Previously, if an escaped newline was followed by a newline or a nul, we'd lex
the escaped newline as a bogus space character. This led to a bunch of
different broken corner cases:
For the pattern "\\\n\0#", we would then have a (horizontal) space whose
spelling ends in a newline, and would decide that the '#' is at the start of a
line, and incorrectly start preprocessing a directive in the middle of a
logical source line. If we were already in the middle of a directive, this
would result in our attempting to process multiple directives at the same time!
This resulted in crashes, asserts, and hangs on invalid input, as discovered by
fuzz-testing.
For the pattern "\\\n" at EOF (with an implicit following nul byte), we would
produce a bogus trailing space character with spelling "\\\n". This was mostly
harmless, but would lead to clang-format getting confused and misformatting in
rare cases. We now produce a trailing EOF token with spelling "\\\n",
consistent with our handling for other similar cases -- an escaped newline is
always part of the token containing the next character, if any.
For the pattern "\\\n\n", this was somewhat more benign, but would produce an
extraneous whitespace token to clients who care about preserving whitespace.
However, it turns out that our lexing for line comments was relying on this bug
due to an off-by-one error in its computation of the end of the comment, on the
slow path where the comment might contain escaped newlines.
llvm-svn: 300515
At present, clang-format mangles Java containing logical right shift operators
('>>>=' or '>>>'), splitting them in two, resulting in invalid code:
public class Minimal {
public void func(String args) {
int i = 42;
- i >>>= 1;
+ i >> >= 1;
return i;
}
}
This adds both forms of logical right shift to the FormatTokenLexer, so
clang-format won't attempt to split them and insert bogus whitespace.
https://reviews.llvm.org/D31652
Patch from Richard Bradfield <bradfier@fstab.me>!
llvm-svn: 299952
clang-format <<END
auto c1 = u8'a';
auto c2 = u'a';
END
Before:
auto c1 = u8 'a';
auto c2 = u'a';
Now:
auto c1 = u8'a';
auto c2 = u'a';
Patch from Denis Gladkikh <llvm@denis.gladkikh.email>!
llvm-svn: 299574
Summary:
The new test case was crashing before. Now it passes
as expected.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D31441
llvm-svn: 299465
clang-format treats MSVC `__super` keyword like all other keywords adding
a single space after. This change disables this behavior for `__super`.
Patch originally by jutocz (thanks!).
Differential Revision: https://reviews.llvm.org/D30932
llvm-svn: 297936
This prevents unwanted fallout from r296664. Specifically in proto formatting,
this changed:
optional Aaaaaaaa aaaaaaaa = 12 [
(aaa) = aaaa,
(bbbbbbbbbbbbbbbbbbbbbbbbbb) = {
aaaaaaaaaaaaaaaaa: true,
aaaaaaaaaaaaaaaa: true
}
];
Into:
optional Aaaaaaaa aaaaaaaa = 12 [
(aaa) = aaaa,
(bbbbbbbbbbbbbbbbbbbbbbbbbb) =
{aaaaaaaaaaaaaaaaa: true, aaaaaaaaaaaaaaaa: true}
];
Which is considered less readable. Generally, it seems preferable to
format such dict literals as blocks rather than contract them to one
line.
llvm-svn: 297696
Summary:
@see is special among JSDoc tags in that it is commonly followed by URLs. The JSDoc spec suggests that users should wrap URLs in an additional {@link url...} tag (@see http://usejsdoc.org/tags-see.html), but this is very commonly violated, with @see being followed by a "naked" URL.
This change special cases all JSDoc lines that contain an @see not to be wrapped to account for that.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D30883
llvm-svn: 297607
Summary:
Previously clang-format would not break after any !. However in TypeScript, ! can be used as a post fix operator for non-nullability:
x.foo()!.bar()!;
With this change, clang-format will wrap after the ! if it is likely a post-fix non null operator.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D30705
llvm-svn: 297606
Summary:
`interface` and `type` are pseudo keywords and cause automatic semicolon
insertion when followed by a line break:
interface // gets parsed as a long variable access to "interface"
VeryLongInterfaceName {
}
With this change, clang-format not longer wraps after `interface` or `type`.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D30874
llvm-svn: 297605
Summary:
This patch makes ContinuationIndenter call breakProtrudingToken only if
NoLineBreak and NoLineBreakInOperand is false.
Previously, clang-format required two runs to converge on the following example with 24 columns:
Note that the second operand shouldn't be splitted according to NoLineBreakInOperand, but the
token breaker doesn't take that into account:
```
func(a, "long long long long", c);
```
After first run:
```
func(a, "long long "
"long long",
c);
```
After second run, where NoLineBreakInOperand is taken into account:
```
func(a,
"long long "
"long long",
c);
```
With the patch, clang-format now obtains in one run:
```
func(a,
"long long long"
"long",
c);
```
which is a better token split overall.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D30575
llvm-svn: 297274
Summary:
This patch enables comment reflowing of lines not matching the comment pragma regex
in multiline comments containing comment pragma lines. Previously, these comments
were dumped without being reindented to the result.
Reviewers: djasper, mprobst
Reviewed By: mprobst
Subscribers: klimek, mprobst, cfe-commits
Differential Revision: https://reviews.llvm.org/D30697
llvm-svn: 297261
Summary:
This patch adds support for namespaces ending in semicolon to the namespace comment fixer.
source:
```
namespace A {
int i;
int j;
};
```
clang-format before:
```
namespace A {
int i;
int j;
} // namespace A;
```
clang-format after:
```
namespace A {
int i;
int j;
}; // namespace A
```
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D30688
llvm-svn: 297140
Summary:
Until now, NamespaceEndCommentFixer was adding missing comments for every run,
which results in multiple end comments for:
```
namespace {
int i;
int j;
}
#if A
int a = 1;
#else
int a = 2;
#endif
```
result before:
```
namespace {
int i;
int j;
}// namespace // namespace
#if A
int a = 1;
#else
int a = 2;
#endif
```
result after:
```
namespace {
int i;
int j;
}// namespace
#if A
int a = 1;
#else
int a = 2;
#endif
```
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D30659
llvm-svn: 297028
Summary:
This patch makes the namespace comment fixer use the number of unwrapped lines
that a namespace spans to detect it that namespace is short, thus not needing
end comments to be added.
This is needed to ensure clang-format is idempotent. Previously, a short namespace
was detected by the original source code lines. This has the effect of requiring two
runs for this example:
```
namespace { class A; }
```
after first run:
```
namespace {
class A;
}
```
after second run:
```
namespace {
class A;
} // namespace
```
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D30528
llvm-svn: 296736
Many things were wrong:
- We didn't always allow wrapping after "as", which can be necessary.
- We used to Undestand the identifier after "as" as a start of a name.
- We didn't properly parse the structure of the expression with "as"
having the precedence of relational operators
llvm-svn: 296659
Summary:
This patch enables namespace end comments under a new flag FixNamespaceComments,
which is enabled for the LLVM and Google styles.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D30405
llvm-svn: 296632
Those blocks are used if C++ code is SWIG-wrapped (see swig.org) and
usually do not contain C++ code. Also cleanup the implementation of for #if 0
and #if false a bit.
llvm-svn: 296605
Summary:
Also limits the blacklisting to only apply when the tag is actually
followed by a parameter in curly braces.
/** @mods {long.type.must.not.wrap} */
vs
/** @const this is a long description that may wrap. */
Reviewers: djasper
Subscribers: klimek, krasimir, cfe-commits
Differential Revision: https://reviews.llvm.org/D30452
llvm-svn: 296467
Summary:
This patch adds a NamespaceEndCommentsFixer TokenAnalyzer for clang-format,
which fixes end namespace comments.
It currently supports inserting and updating existing wrong comments.
Example source:
```
namespace A {
int i;
}
namespace B {
int j;
} // namespace A
```
after formatting:
```
namespace A {
int i;
} // namespace A
namespace B {
int j;
} // namespace B
```
Reviewers: klimek, djasper
Reviewed By: djasper
Subscribers: klimek, mgorny
Differential Revision: https://reviews.llvm.org/D30269
llvm-svn: 296341
Summary:
Async arrow functions should be marked with a whitespace after the async keyword, before the parameter list:
x = async () => foo();
Before:
x = async() => foo();
This makes it easier to tell apart an async arrow function from a call to a function called async.
Reviewers: bkramer
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D30399
llvm-svn: 296330
r289428 added a separate language kind for Objective-C, but kept many
"Language == LK_Cpp" checks untouched. This introduced a "IsCpp()"
method that returns true for both C++ and Objective-C++, and replaces
all comparisons of Language with LK_Cpp with calls to this new method.
Also add a lot more test coverge for formatting things in LK_ObjC mode,
by having FormatTest's verifyFormat() test for LK_ObjC everything that's
being tested for LK_Cpp at the moment.
Fixes PR32060 and many other things.
llvm-svn: 296160
Specifically, similar to other blocks, clang-format now wraps both
after "${" and before the corresponding "}", if the contained
expression spans multiple lines.
llvm-svn: 295663
Before:
var someValue = (v as aaaaaaaaaaaaaaaaaaaa<T>[
]).someFunction(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
After:
var someValue = (v as aaaaaaaaaaaaaaaaaaaa<T>[])
.someFunction(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
llvm-svn: 295658
This can lead to bad behavior with macros that are used to annotate
functions (e.g. ALWAYS_INLINE).
Before, this:
ALWAYS_INLINE ::std::string getName() ...
was turned into:
ALWAYS_INLINE::std::string getName() ...
If it turns out that clang-format is failing to clean up a lot of the
existing spaces now, we can add more analyses of the identifier. It
should not currently. Cases where clang-format breaks nested name
specifiers should be fine as clang-format wraps after the "::". Thus, a
line getting longer and then shorter again should lead to the same
original code.
llvm-svn: 295437
Summary: With a growing suite of comment-related tests, it makes sense to take them out of the main test file. No functional changes.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek, mgorny
Differential Revision: https://reviews.llvm.org/D29713
llvm-svn: 294439
Summary:
Make the comment alignment respect sections of line comments originally alinged
with the next token. Until now the decision how to break a continuous sequence
of line comments into sections was taken without reference to the next token.
source:
```
class A {
public: // comment about public
// comment about a
int a;
}
```
format before:
```
class A {
public: // comment about public
// comment about a
int a;
}
```
format after:
```
class A {
public: // comment about public
// comment about a
int a;
}
```
Reviewers: djasper, klimek
Reviewed By: klimek
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D29626
llvm-svn: 294435
Summary:
In JavaScript, object literals can contain methods:
var x = {
a() { return 1; },
};
Previously, clang-format always parsed nested {} inside a braced list as
further braced lists. Special case this logic for JavaScript to try
parsing as a braced list, but fall back to parsing as a child block.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D29656
llvm-svn: 294315
Summary:
Regex detection would incorrectly classify a trailing `!` operator
(nullability cast) followed by a `/` as the start of a regular
expression literal. This fixes code such as:
var foo = x()! / 10;
Which would previously parse a regexp all the way to the end of the
source file (or next `/`).
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D29634
llvm-svn: 294304
Summary:
In JavaScript, classes are expressions, so they can appear e.g. in
argument lists.
var C = foo(class {
bar() {
return 1;
}
};
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D29635
llvm-svn: 294302
Fix for the formatting options combination of
BreakBeforeBinaryOperators: All, AlignAfterOpenBracket: AlwaysBreak not
handling long templates correctly. This patch allows a break after an
opening left parenthesis, TemplateOpener, or bracket when both options
are enabled.
Patch by Daphne Pfister, thank you!
Fixes llvm.org/PR30304.
llvm-svn: 294179
Summary:
The comment aligner was skipping over newly broken comment lines. This patch fixes that.
source:
```
int ab; // line
int a; // long long
```
format with column limit 15 before:
```
int ab; // line
int a; // long
// long
```
format with column limit 15 after:
```
int ab; // line
int a; // long
// long
```
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D29486
llvm-svn: 293997
Summary:
The comment reflower wasn't taking comment pragmas as reflow stoppers. This patch fixes that.
source:
```
// long long long long
// IWYU pragma:
```
format with column limit = 20 before:
```
// long long long
// long IWYU pragma:
```
format with column limit = 20 after:
```
// long long long
// long
// IWYU pragma:
```
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D29450
llvm-svn: 293898
Summary:
The breaking of line comment sections was misaligning the case where the first comment line is on an unwrapped line containing newlines. In this case, the breaking column must be based on the source column of the last token that is preceded by a newline, not on the first token of the unwrapped line.
source:
```
enum A {
a, // line 1
// line 2
};
```
format before:
```
enum A {
a, // line 1
// line 2
};
```
format after:
```
enum A {
a, // line 1
// line 2
};
```
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D29444
llvm-svn: 293891
Without alignment, there is no clean separation between the arguments, even if
there are only two.
Before:
aaaaaaaaaaaaaa(
aaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa +
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
After:
aaaaaaaaaaaaaa(aaaaaaaaaaaa,
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa +
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
llvm-svn: 293875
Summary:
Comment reflower was adding untouchable tokens in case two consecutive comment lines are aligned in the source code. This disallows the whitespace manager to re-indent them later.
source:
```
int i = f(abc, // line 1
d, // line 2
// line 3
b);
```
Since line 2 and line 3 are aligned, the reflower was marking line 3 as untouchable; however the three comment lines need to be re-aligned.
output before:
```
int i = f(abc, // line 1
d, // line 2
// line 3
b);
```
output after:
```
int i = f(abc, // line 1
d, // line 2
// line 3
b);
```
Reviewers: djasper
Reviewed By: djasper
Subscribers: sammccall, cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D29383
llvm-svn: 293755
This rows back on r288120, r291801 and r292110. I apologize in advance
for the churn. All of those revisions where meant to make the wrapping
of RHS expressions more consistent. However, now that they are
consistent, we seem to be a bit too eager.
The reasoning here is that I think it is generally correct that we want
to line-wrap before multiline RHS expressions (or multiline arguments to
a function call). However, if there are only two of such operands or
arguments, there is always a clear vertical separation between them and
the additional line break seems much less desirable.
Somewhat good examples are expressions like:
EXPECT_EQ(2, someLongExpression(
orCall));
llvm-svn: 293752
Summary:
The reflower didn't measure precisely the line column of a line in the middle of
a line comment section that has a prefix that needs to be adapted.
source:
```
/// a
//b
```
format before:
```
/// a
//b
```
format after:
```
/// a
// b
```
Reviewers: djasper
Reviewed By: djasper
Subscribers: sammccall, cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D29329
llvm-svn: 293641
This only affects expressions inside ${} scopes of template strings.
Here, we want to indent relative to the surrounding template string and
not the surrounding expression. Otherwise, this can create quite a mess.
Before:
var f = `
aaaaaaaaaaaaaaaaaa: ${someFunction(
aaaaa + //
bbbb)}`;
After:
var f = `
aaaaaaaaaaaaaaaaaa: ${someFunction(
aaaaa + //
bbbb)}`;
llvm-svn: 293636
Summary:
The reflower was not taking into account the additional leading whitespace in block comment lines.
source:
```
{
/*
* long long long long
* long
* long long long long
*/
}
```
format (with column limit 20) before:
```
{
/*
* long long long
* long long long long
* long long
*/
}
```
format after:
```
{
/*
* long long long
* long long long
* long long long
*/
}
```
Reviewers: djasper, klimek
Reviewed By: djasper
Subscribers: cfe-commits, sammccall, klimek
Differential Revision: https://reviews.llvm.org/D29326
llvm-svn: 293633
Summary:
This fixes a regression that causes example:
```
enum A {
a, // line a
// line b
b
};
```
to be formatted as follows:
```
enum A {
a, // line a
// line b
b
};
```
Reviewers: djasper, klimek
Reviewed By: klimek
Subscribers: cfe-commits, sammccall, djasper, klimek
Differential Revision: https://reviews.llvm.org/D29322
llvm-svn: 293624
Before:
var f = `aaaaaaaaaaaaa:${aaaaaaa
.aaaaa} aaaaaaaa
aaaaaaaaaaaaa:${aaaaaaa.aaaaa} aaaaaaaa`;
After:
var f = `aaaaaaaaaaaaa:${aaaaaaa.aaaaa} aaaaaaaa
aaaaaaaaaaaaa:${aaaaaaa.aaaaa} aaaaaaaa`;
llvm-svn: 293622
Summary:
This patch stops reflowing comment lines starting with '@', since they commonly
have a special meaning.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D29323
llvm-svn: 293617
Summary:
Consider formatting the following code fragment with column limit 20:
```
{
// line 1
// line 2\
// long long long line
}
```
Before this fix the output is:
```
{
// line 1
// line 2\
// long long
long line
}
```
This patch fixes a regression that breaks the last comment line without
adding the '//' prefix.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D29298
llvm-svn: 293548
Summary:
The following two comment lines form a single comment section:
```
if (1) { // line 1
// line 2
}
```
This is because the break of a comment section was based on the original column
of the first token of the previous line (in this case, the 'if').
This patch splits these two comment lines into different sections by taking into
account the original column of the right brace preceding the first line comment
where applicable.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D29291
llvm-svn: 293539
This had significant negative consequences and I don't have a good
solution for it yet.
Before:
var string =
[
'aaaaaa',
'bbbbbb',
]
.join('+');
After:
var string = [
'aaaaaa',
'bbbbbb',
].join('+');
llvm-svn: 293465
Summary:
The MPEG transport stream file format also uses ".ts" as its file extension.
This change detects its specific framing format (0x47 every 189 bytes) and
simply ignores MPEG TS files.
Reviewers: djasper, sammccall
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D29186
llvm-svn: 293270
Summary:
This presents a version of the comment reflowing with less mutable state inside
the comment breakable token subclasses. The state has been pushed into the
driving breakProtrudingToken method. For this, the API of BreakableToken is enriched
by the methods getSplitBefore and getLineLengthAfterSplitBefore.
Reviewers: klimek
Reviewed By: klimek
Subscribers: djasper, klimek, mgorny, cfe-commits, ioeric
Differential Revision: https://reviews.llvm.org/D28764
llvm-svn: 293055
This fixes clang-format not formatting if fallback-style is explicitly set to
"none", and either a config file is found or YAML is passed in without a
"BasedOnStyle". With this change, passing "none" in these cases will have no
affect, and LLVM style will be used as the base style.
Differential Revision: https://reviews.llvm.org/D28844
llvm-svn: 292562
Change the contract of GetStyle so that it returns an error when an error occurs
(i.e. when it writes to stderr), and only returns the fallback style when it
can't find a configuration file.
Differential Revision: https://reviews.llvm.org/D28081
llvm-svn: 292174
Before:
aaaaaaaaaaaaaaaaaa(aaaaaaaa, aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa::
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,
aaaaaaaaaaaaaaaaaaaaa);
After:
aaaaaaaaaaaaaaaaaa(aaaaaaaa,
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa::
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,
aaaaaaaaaaaaaaaaaaaaa);
No new test cases, as the existing ones cover this fairly well.
llvm-svn: 292110
Summary: Change r291428 introduced ASI detection after closing curly braces. That would generally be correct, however this breaks indentation for structural statements. What happens is that CompoundStatementIndenter increases indentation for the current line, then after reading ASI creates a new line (with the increased line level), and only after the structural parser sees e.g. the if/then/else branch closed, line level is reduced. That leads to the new line started by ASI having a level too high.
Reviewers: djasper
Subscribers: sammccall, cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D28763
llvm-svn: 292099
Here, the optimization to not line wrap when it would not lead to a
reduction in columns was overwriting and enforced break that we want to
do no matter what.
Before:
int i = someFunction(
aaaaaaa,
0).aaa(aaaaaaaaaaaaa) *
aaaaaaa +
aaaaaaa;
After:
int i = someFunction(aaaaaaa, 0)
.aaa(aaaaaaaaaaaaa) *
aaaaaaa +
aaaaaaa;
llvm-svn: 291974
Specifically, wrap before them if they are multi-line so that we don't
create long hanging indents. This prevents having a lot of code
indented a lot in some cases.
Before:
someFunction(Param, {List1, List2,
List3});
After:
someFunction(Param,
{List1, List2,
List3});
llvm-svn: 291801
Summary:
Automatic semicolon insertion should break import and export statements:
Before, this would format on one line:
// Note: no semi after 'x' below!
import {x} from 'x'
export function foo() {}
Into:
import {x} from 'x' export function foo() {}
With this change, the statements get separated.
This also improves automatic semicolon insertion to consider closing
braces preceding declarations and statements.
Reviewers: klimek
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28465
llvm-svn: 291428
Summary:
Before:
declare function foo();
let x = 1;
After:
declare function foo();
let x = 1;
The problem was that clang-format would unconditionally try to parse a child block, even though ambient function declarations do not have a body (similar to forward declarations).
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D28246
llvm-svn: 290959
Modify getStyle to use vfs::FileSystem::makeAbsolute just like FS.addFile does,
rather than sys::fs::make_absolute. The latter gets the CWD from the platform,
while the former expects it to be set by the client, causing a mismatch when
converting relative paths to absolute.
Differential Revision: https://reviews.llvm.org/D27971
llvm-svn: 290319
Members that are themselves wrapped in fake parentheses would lead to
AvoidBinPacking be set on the wrong ParenState.
After:
vector<int> aaaa = {
aaaaaa.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,
aaaaaa.aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa,
aaaaaa.aaaaaaa,
aaaaaa.aaaaaaa,
aaaaaa.aaaaaaa,
aaaaaa.aaaaaaa,
};
Before we were falling back to bin-packing these.
llvm-svn: 290259
While for <<-operators often used in log statments, a single key value
pair is always on the second operator, e.g.
llvm::errs() << "aaaaa=" << aaaaa;
It is on the first operator for plus- or comma-concatenated strings:
string s = "aaaaaaaaaa: " + aaaaaaaa;
(the "=" not counting because that's a different operator precedence)
llvm-svn: 290177
Before:
SomeLongLoggingStatementOrMacro() << "Some long text "
<< some_variable << "\n";
Before:
SomeLongLoggingStatementOrMacro()
<< "Some long text " << some_variable << "\n";
Short logging statements are already special cased in a different part
of the code.
llvm-svn: 290094
We still want to try in linewrap within single elements of a 1-column
list.
After:
Type *Params[] = {PointerType::getUnqual(FunctionType::get(
Builder.getVoidTy(), Builder.getInt8PtrTy(), false)),
Builder.getInt8PtrTy(),
Builder.getInt32Ty(),
LongType,
LongType,
LongType};
Before:
No line break in the first element, so column limit violation.
llvm-svn: 290090
column limit.
Single-column layout basically means that we format the list with one
element per line. Not doing that when there is a column limit violation
doesn't change the fact that there is an item that doesn't fit within
the column limit.
Before (with a column limit of 30):
std::vector<int> a = {
aaaaaaaa, aaaaaaaa,
aaaaaaaa, aaaaaaaa,
aaaaaaaaaa, aaaaaaaa,
aaaaaaaaaaaaaaaaaaaaaaaaaaa};
After:
std::vector<int> a = {
aaaaaaaa,
aaaaaaaa,
aaaaaaaa,
aaaaaaaa,
aaaaaaaaaa,
aaaaaaaa,
aaaaaaaaaaaaaaaaaaaaaaaaaaa};
(and previously we would have formatted like "After" it wasn't for the one
item that is too long)
llvm-svn: 290084
While C(++) and ObjC are generally formatted the same way and can be
mixed, people might want to choose different styles based on the
language. This patch recognizes .m and .mm files as ObjC and also
implements a very crude detection of whether or not a .h file contains
ObjC code. This can be improved over time.
Also move most of the ObjC tests into their own test file to keep file
size maintainable.
llvm-svn: 289428
Specifically, if the RHS of a comma is a complex binary expression and
spans multiple lines, insert a line break before it. This usually is
often more readable compared to producing a hanging indent. See changes
in FormatTest.cpp for examples.
llvm-svn: 288120
Actual regression was introduced in r272668. This revision fixes JS script, but
also regress Cpp case. It manifests with spaces added when template is followed
with array. Bug 30527 mentions case of array as a nested template type
(foo<bar<baz>[]>). Fix is to detect such case and to prevent treating it as
array initialization, but as a subscript case. However, before r272668, this
case was treated simple because we were detecting it as a StartsObjCMethodExpr.
Same was true for other similar case - array of templates (foo<int>[]). This
patch tries to address two problems: 1) fixing regression 2) making sure both
cases (array as a nested type, array of templates) which were entering
StartsObjCMethodExpr branch are handled now appropriately.
https://reviews.llvm.org/D26163
Patch from Branko Kokanovic <branko@kokanovic.org>!
llvm-svn: 286507
Summary:
During clang-format source lexing >> and << operators are split and
treated as two less/greater operators but column position of following
tokens was not adjusted accordingly.
Fixes PR26887
Patch by Paweł Żukowski.
Reviewers: djasper
Subscribers: malcolm.parsons, mprobst, klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D25439
llvm-svn: 285934
Reasoning:
- ExpressionParser uses a lot of stack for these, bad in some environments.
- Our formatting algorithm is N^3 and gets really slow.
- The resulting formatting is unlikely to be any good.
- This is probably generated code we're formatting by accident.
We treat these as unparseable, and signal incomplete formatting. 50 is
an arbitrary number, I've only seen real problems from ~150 levels.
Patch by Sam McCall. Thank you.
llvm-svn: 285570
Summary:
Previously, automatic semicolon insertion would add an unwrapped line
when a template string contained a line break.
var x = `foo${
bar}`;
Would be formatted with `bar...` on a separate line and no indent.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D25675
llvm-svn: 284807
Summary:
Remove colon and commas after replacing constructor body with = default.
Fix annotation of TT_CtorInitializerColon when preceded by a comment.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D25768
llvm-svn: 284732
Summary:
append newline after code when inserting new headers at the end of the
code which does not end with newline.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D21026
llvm-svn: 283330
Fixes the following:
BOOL (^aaa)(void) = ^BOOL {
};
The first BOOL's token was getting set to TT_FunctionAnnotationRParen
incorrectly, which was causing an unexpected newline after (^aaa). This
was introduced in r245846.
Patch by Kent Sutherland, thank you!
llvm-svn: 282448
Summary:
- If a replacement has offset UINT_MAX, length 0, and a replacement text
that is an #include directive, this will insert the #include into the
correct block in the \p Code.
- If a replacement has offset UINT_MAX, length 1, and a replacement text
that is the name of the header to be removed, the header will be removed
from \p Code if it exists.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D24829
llvm-svn: 282253
Summary:
Previously, clang-format would always insert an additional line break after the
import block if the main body started with a comment, due to loosing track of
the first non-import line.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D24708
llvm-svn: 281888
Summary:
`// taze: ... from ...` comments are used help tools where a
specific global symbol comes from.
Before:
// taze: many, different, symbols from
// 'some_long_location_here'
After:
// taze: many, different, symbols from 'some_long_location_here'
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D24477
llvm-svn: 281857
Summary:
Before when a semicolon was missing after a boolean literal:
a = true
return 1;
clang-format would parse this as one line and format as:
a = true return 1;
It turns out that C++ does not consider `true` and `false` to be literals, we
have to check for that explicitly.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D24574
llvm-svn: 281856
The attempt to fix requoting behavior in r280487 after changes to
tooling::Replacements are incomplete. We essentially need to add to
replacements at the same position, one to insert a line break and one to
change the quoting and that's incompatible with the new
tooling::Replacement API, which does not allow for order-dependent
Replacements. To make the order clear, Replacements::merge() has to be
used, but that requires the merged Replacement to actually refer to the
changed text, which is hard to reproduce for the requoting.
This change fixes the behavior by moving the requoting to a completely
separate pass. The added benefit is that no weird ColumnWidth
calculations are necessary anymore and this should just work even if we
implement string literal splitting in the future.
llvm-svn: 280874
Summary:
When code contains a comment between `return` and the value:
return /* lengthy comment here */ (
lengthyValueComesHere);
Do not wrap before the comment, as that'd break the code through JS' automatic
semicolon insertion.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D24257
llvm-svn: 280730
Summary:
When formatting source code that needs both requoting and reindentation,
merge the replacements to avoid erroring out for conflicting replacements.
Also removes the misleading Replacements parameter from the
TokenAnalyzer API.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D24155
llvm-svn: 280487
Summary:
Default imports appear outside of named bindings in curly braces:
import A from 'a';
import A, {symbol} from 'a';
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D23973
llvm-svn: 280486
Summary:
User feedback is that they expect *all* imports to be sorted if any import was
affected by a change, not just imports up to the first non-affected line, as
clang-format currently does.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D23972
llvm-svn: 280485
JavaScript template strings can be nested arbitrarily:
foo = `text ${es.map(e => { return `<${e}>`; })} text`;
This change lexes nested template strings using a stack of lexer states to
correctly switch back to template string lexing on closing braces.
Also, reuse the same stack for the token-stashed logic.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D22431
llvm-svn: 279727
Summary: When sorting #includes, #include directives that have the same text will be deduplicated when sorting #includes, and only the first #include in the duplicate #includes remains. If the `Cursor` is provided and put on a deleted #include, it will be put on the remaining #include in the duplicate #includes.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D23274
llvm-svn: 278206
Summary:
This is required for compliance with the Mozilla style guide.
This is a rebase+minor change of Birunthan Mohanathas's patch
Reviewers: djasper
Subscribers: klimek, cfe-commits, opilarium
Differential Revision: https://reviews.llvm.org/D23317
llvm-svn: 278121
Summary:
- Implement clang::tooling::Replacements as a class to provide interfaces to
control how replacements for a single file are combined and provide guarantee
on the order of replacements being applied.
- tooling::Replacements only contains replacements for the same file now.
Use std::map<std::string, tooling::Replacements> to represent multi-file
replacements.
- Error handling for the interface change will be improved in followup patches.
Reviewers: djasper, klimek
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D21748
llvm-svn: 277335
I am not sure exactly which test breakage Martin was trying to fix in
r273694. For now, fix the behavior for top-level conditionals, which
(surprisingly) are actually used somewhat commonly.
llvm-svn: 275183
Summary:
return llvm::Expected<> to carry error status and error information.
This is the first step towards introducing "Error" into tooling::Replacements.
Reviewers: djasper, klimek
Subscribers: ioeric, klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D21601
llvm-svn: 275062
Summary: ASCII case sorting does not help finding imported symbols quickly, and it is common to have e.g. class Foo and function fooFactory exported/imported from the same file.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D22146
llvm-svn: 274977
Summary: Includes parenthesized type expressions and type aliases.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D21597
llvm-svn: 273603
Summary:
'as' is a pseudo operator, so automatic semicolon insertion kicks in and the
code fails to part.
Reviewers: djasper
Subscribers: klimek
Differential Revision: http://reviews.llvm.org/D21576
llvm-svn: 273422
Before (when aligning & to the right):
SomeType MemberFunction(const Deleted &) const&;
After:
SomeType MemberFunction(const Deleted &) const &;
This also applies to variable declarations, e.g.:
int const * a;
However, this form is very uncommon (most people would write
"const int* a" instead) and contracting to "const*" might actually send
the wrong signal of what the const binds to.
llvm-svn: 272537
Summary:
Do not insert whitespace preceding the "!" postfix operator. This is an
incomplete fix, but should cover common usage.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: http://reviews.llvm.org/D21204
llvm-svn: 272524
Summary: This also fixes union type formatting in function parameter types.
Before: function x(path: number| string) {}
After: function x(path: number|string) {}
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D21206
llvm-svn: 272330
Summary:
The JavaScript import sorter has a corner condition that can cause the overall
source text length to shrink. This change circumvents the issue by appending
trailing space in the line after the import blocks to match at least the
previous source code length.
This needs a better long term fix, but this fixes the immediate issue.
Reviewers: alexeagle, djasper
Subscribers: klimek
Differential Revision: http://reviews.llvm.org/D21108
llvm-svn: 272142
Summary:
[clang-format] skip empty lines and comments in the top of the code when inserting new headers.
Pair-programmed with @hokein
Reviewers: djasper
Subscribers: ioeric, cfe-commits, hokein, klimek
Differential Revision: http://reviews.llvm.org/D20898
llvm-svn: 271664
Summary: ASI did not handle the ES6 `as` operator correctly.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D20817
llvm-svn: 271401
Summary:
When a replacement's offset is set to UINT_MAX or -1U, it is treated as
a header insertion replacement by cleanupAroundReplacements(). The new #include
directive is then inserted into the correct block.
Reviewers: klimek, djasper
Subscribers: klimek, cfe-commits, bkramer
Differential Revision: http://reviews.llvm.org/D20734
llvm-svn: 271276
Summary:
Shebang lines (`#!/bin/blah`) can be used in JavaScript scripts to indicate
they should be run using e.g. node. This change treats # lines on the first line
as line comments.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D20632
llvm-svn: 271185
Summary:
Only treat the sequence `async function` as the start of a function expression,
as opposed to every occurrence of the token `async` (whoops).
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D20737
llvm-svn: 271184
Summary:
This change automatically sorts ES6 imports and exports into four groups:
absolute imports, parent imports, relative imports, and then exports. Exports
are sorted in the same order, but not grouped further.
To keep JS import sorting out of Format.cpp, this required extracting the
TokenAnalyzer infrastructure to separate header and implementation files.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: http://reviews.llvm.org/D20198
llvm-svn: 270203
Summary:
Simply looking at the final text greatly simplifies the algorithm and also
fixes a reported issue. This requires duplicating the "actual encoding width"
logic, but that seems cleaner than the column acrobatics before.
Reviewers: djasper, bkramer
Subscribers: cfe-commits, klimek
Differential Revision: http://reviews.llvm.org/D20208
llvm-svn: 269747
Summary:
After applying replacements, redundant code like extra commas or empty namespaces
might be introduced. Fixer can detect and remove any redundant code introduced by replacements.
The current implementation only handles redundant commas.
Reviewers: djasper, klimek
Subscribers: ioeric, mprobst, klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D18551
llvm-svn: 267416
Summary:
`interface` can be used as a fee standing identifier in JavaScript/TypeScript.
This change uses the heuristic of whether it's followed by another identifier
as an indication.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D19240
llvm-svn: 266789
Summary:
Change `import` and `export` parsing to special case the renaming
syntax (`import x, {y as bar} ...`, `export {x}`) and otherwise just
parse a regular structural element.
This simplifies the code a bit and should be more correct - it's easier
to recognise the specific import syntax than to recognise arbitrary
expressions and declarations.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: http://reviews.llvm.org/D19242
llvm-svn: 266743
Indentation of the last line was reset to the initial indentation of the block when reaching EOF.
Patch by Maxime Beaulieu
Differential Revision: http://reviews.llvm.org/D19065
llvm-svn: 266321
Summary: Just to ensure no regressions, this already works fine.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: http://reviews.llvm.org/D18950
llvm-svn: 265922
While I am not personally convinced about the usefulness of this
construct, we should break it.
Before:
if (a) label:
f();
After:
if (a)
label:
f();
llvm-svn: 265545
Summary:
formatAndApplyAllReplacements takes a set of Replacements, applies them on a
Rewriter, and reformats the changed code.
Reviewers: klimek, djasper
Subscribers: ioeric, klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D17852
llvm-svn: 264745
Summary:
Previously, format::getStyle assumes that the given file resides in
the real file system, which prevents the use of virtual file system in testing etc.
This patch adds a parameter in format::getStyle interface so that users can specify
the right file system. By default, the file system is the real file system.
Reviewers: djasper, klimek
Subscribers: cfe-commits, klimek
Differential Revision: http://reviews.llvm.org/D18399
llvm-svn: 264253
"import ... from '...';" and "export ... from '...';" should be treated
the same as goog.require/provide/module/forwardDeclare calls.
Patch by Martin Probst.
llvm-svn: 264055
The operators | and & in types, as opposed to the bitwise operators,
should not have whitespace around them (e.g. `Foo<Bar|Baz>`).
Patch by Martin Probst. Thank you.
llvm-svn: 263961
This patch adds a regular expression to configure suffixes of an
included file to check whether it is the "main" include of the current
file. Previously, clang-format has allowed arbitrary suffixes on the
formatted file, which is still the case when no IncludeMainRegex is
specified.
llvm-svn: 263943
If a call takes a single argument, using AlwaysBreak can lead to lots
of wasted lines and additional indentation without improving the
readability in a significant way.
Before:
caaaaaaaaaaaall(
caaaaaaaaaaaall(
caaaaaaaaaaaall(
caaaaaaaaaaaaaaaaaaaaaaall(aaaaaaaaaaaaaa, aaaaaaaaa))));
After:
caaaaaaaaaaaall(caaaaaaaaaaaall(caaaaaaaaaaaall(
caaaaaaaaaaaaaaaaaaaaaaall(aaaaaaaaaaaaaa, aaaaaaaaa))));
llvm-svn: 263709
Automatic Semicolon Insertion can only be properly handled by parsing
source code. However conservatively catching just a few, common
situations prevents breaking code during development, which greatly
improves usability.
JS code should still use semicolons, and ASI code should be flagged by
a compiler or linter.
Patch by Martin Probst. Thank you.
llvm-svn: 263470
Turns "foo" into 'foo' (or vice versa, depending on configuration).
This makes it more convenient to follow the Google JavaScript style
guide:
https://google.github.io/styleguide/javascriptguide.xml?showone=Strings#Strings
This functionality is behind the option "JavaScriptQuotes", which can be:
* "leave" (no re-quoting)
* "single" (change to single quotes)
* "double" (change to double quotes)
This also changes single quoted JavaScript string literals to be treated
as tok::string_literal, not tok::char_literal, which fixes two unrelated
tests.
Patch by Martin Probst. Thank you.
llvm-svn: 262534
This is a commonly useful feature to have, and we have implemented it
multiple times with different kinds of bugs. This implementation
centralizes the idea in a set of functions that we can then use from the various
tools.
Reverts r262234, which is a revert of r262232, and puts the functions
into FOrmat.h, as they are closely coupled to clang-format, and we
otherwise introduce a cyclic dependency between libFormat and
libTooling.
Patch by Eric Liu.
llvm-svn: 262323
In particular, make it more expensive than breaking after the return
type of a function definition/declaration.
Before:
template <typename T>
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaa<
T>::aaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaa);
After:
template <typename T>
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaa<T>::aaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaa);
llvm-svn: 260497
Before:
int i = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ?
/*bbbbbbbbbbbbbbbbbbbb=*/bbbbbbbbbbbbbbbbbbbbbbbbb :
ccccccccccccccccccccccccccc;
After:
int i = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ?
/*bbbbbbbbbbbbbbbbbbbb=*/bbbbbbbbbbbbbbbbbbbbbbbbb :
ccccccccccccccccccccccccccc;
llvm-svn: 259670
Summary:
This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html
"This is the way [autoconf] ends
Not with a bang but a whimper."
-T.S. Eliot
Reviewers: chandlerc, grosbach, bob.wilson, echristo
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D16472
llvm-svn: 258862
clang-format only works for JavaScript code, if all the semicolons are
present anyway, so this linebreak can never be desired.
Before (with appropriate statement lengths or column limit):
return
[ aaa ];
After:
return [
aaaa
];
llvm-svn: 257741
After reading the style guides again, they don't actually say how to
pack or not pack array literals. Based on some user reports, array
initializers can unnecessarily get quite long if they contain many
small elements. Array literals with trailing commas are still formatted
one per line so that users have a way to opt out of the packing.
Before:
var array = [
aaaaaa,
aaaaaa,
aaaaaa,
aaaaaa,
aaaaaa,
aaaaaa,
aaaaaa,
aaaaaa,
aaaaaa,
aaaaaa
];
After:
var array = [
aaaaaa, aaaaaa, aaaaaa, aaaaaa, aaaaaa, aaaaaa, aaaaaa, aaaaaa, aaaaaa,
aaaaaa, aaaaaa
];
llvm-svn: 257615
Before:
export abstract class X {y: number;}
(and all sorts of other havoc in more complicated cases).
After:
export abstract class X { y: number; }
llvm-svn: 257451
As soon as a comment had whitespace changes inside of the token, we
couldn't identify the whole comment as a trailing comment anymore and
alignment stopped working. Add a new boolean to Change for this special
case and fix trailing comment identification to use it.
This also changes WhitespaceManager to sum the length of all Changes
inside of a token into the first Change.
Before this fix
int xy; // a
int z; //b
became
int xy; // a
int z; // b
with this patch we immediately get to:
int xy; // a
int z; // b
Differential Revision: http://reviews.llvm.org/D16058
llvm-svn: 257341
r257257 change the way clang-format enforces line breaks after a
templated type has been line-wrapped. This was to fix an incorrect line
break if BinPackParameters is set to false. However, it also leads to
an unwanted line break in a different case. Thus, for now, only do this
when BinPackParameters is false. This isn't ideal yet, but helps us
until we have a better solution.
With BinPackParameters:
Before:
void fffffffffff(aaaaaaaaaaaaaaaaaaaaaaaaaaa<aaaaaaaaaaaaaaaaaaaaaaa,
aaaaaaaaaa> aaaaaaaaaa);
After:
void fffffffffff(
aaaaaaaaaaaaaaaaaaaaaaaaaaa<aaaaaaaaaaaaaaaaaaaaaaa, aaaaaaaaaa>
aaaaaaaaaa);
llvm-svn: 257325
Previously, all whitespace characters would increase the starting
column, which doesn't make sense. This fixes a problem, e.g. with the
length calculation in JS template strings.
llvm-svn: 257267
Starting here:
int x; // Format this line only.
int xx; //
int xxxxx; //
Before:
int x; // Format this line only.
int xx; //
int xxxxx; //
After:
int x; // Format this line only.
int xx; //
int xxxxx; //
llvm-svn: 257258
Before (example is JS, but also applies to C++):
return [
aaaa()
.bbbbbbbb('A'),
aaaa().bbbbbbbb('B'),
aaaa().bbbbbbbb('C'),
];
After:
return [
aaaa().bbbbbbbb('A'),
aaaa().bbbbbbbb('B'),
aaaa().bbbbbbbb('C'),
];
llvm-svn: 257079
r256750 has been leading to an undesired behavior:
aaaaaaaaaa
.aaaaaaaaaaaaaaaaaaaaaaaa.aaaaaa(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
This change increases penalty for wrapping before member accesses that aren't
calls. Thus, this is again formatted as (as it has been before r256750):
aaaaaaaaaa.aaaaaaaaaaaaaaaaaaaaaaaa.aaaaaa(
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);
llvm-svn: 256830
Previously, the [] in the following example were recognized as an array
subscript leading to weird indentation.
Before:
var aaaa = aaaaa || // wrap
[];
After:
var aaaa = aaaaa || // wrap
[];
llvm-svn: 256753
initializers. For now, only use it for 20 items or more. Otherwise,
clang-format formats these one-per-line and thus increases the vertical
code size a lot.
llvm-svn: 256246
Before, the first (non-system) header in a file was considered to be
the main include. This is conservative as it makes clang-format change
the #include order less often. Instead implement some basic usage of
the filename itself. With this patch, clang-format considers every
header to be a main include if the header file's basename is a prefix
to the filename the #include is in.
llvm-svn: 256148
This changes the behavior of AlwaysBreakAfterDeclarationReturnType
so that it supports breaking after declarations, definitions, or
both.
Differential Revision: http://reviews.llvm.org/D10370
Reviewed By: Daniel Jasper
llvm-svn: 256046
Specifically, it is sometimes necessary to keep certain #includes as
the first #include, even before the main #include for a .cc file.
Switching the category to be signed instead of unsigned isn't ideal,
but it seems as good of an option as any and is fully backwards
compatible.
llvm-svn: 255757
Revision 251405 added AlwaysBreak to support Google's JavaScript style. This
changeset complete existing AlignsAfterOpenBracket tests to exercise
AlwaysBreak for C++.
I thought this would be worthwhile. With this option we can support request
from http://lists.llvm.org/pipermail/cfe-dev/2015-May/042942.html, that had
been requested a few times. This also partially solve related Bug 23422 and is
probably sufficient for most people.
AlignAfterOpenBracket = FormatStyle::BAS_AlwaysBreak;
BinPackArguments = false;
BinPackParameters = false;
With these setting we obtain this formatting:
void fooWithAVeryLongParamList(
int firstParameter,
int secondParameter
int lastParameter)
{
object.alsoThisDoenstFitSoIBreakImmidiatly(
firstParameter,
secondParameter,
lastParameter);
}
Patch by Jean-Philippe Dufraigne, thank you.
llvm-svn: 255486
before it is not a closing parenthesis.
Otherwise, this frequently leads to "hanging" indents that users
perceive as "weird".
Before:
return !soooooooooooooome_map.insert(
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa)
.second;
After:
return !soooooooooooooome_map
.insert(aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa)
.second;
llvm-svn: 254933
This has seen quite some usage and I am not aware of any issues. Also
add a style option to enable/disable include sorting. The existing
command line flag can from now on be used to override whatever is set
in the style.
llvm-svn: 253202
unaffected lines with incorrect initial indent.
Starting from:
namespace {
int i; // There shouldn't be indentation here.
int j; // <- call clang-format on this line.
}
Before:
namespace {
int i;
int j;
}
After:
namespace {
int i;
int j;
}
llvm-svn: 251824
Summary:
With this change, clang-format stops formatting when either it leaves
the current scope or when it comes back to the initial scope after
going into a nested one.
Reviewers: klimek
Subscribers: cfe-commits, klimek
Differential Revision: http://reviews.llvm.org/D14213
llvm-svn: 251760
Correct handling for C++17 inline namespaces. We would previously fail to
identify the inline namespaces as a namespace name since multiple ones may be
concatenated now with C++17.
llvm-svn: 251690
Summary: This is especially important so that if a change is solely inserting a block around a few statements, clang-format-diff.py will still clean up and add indentation to the inner parts.
Reviewers: klimek
Subscribers: cfe-commits, klimek
Differential Revision: http://reviews.llvm.org/D14105
llvm-svn: 251474
Specifically, don't wrap between the {} of an empty constructor if the
"}" falls on column 81 and ConstructorInitializerAllOnOneLineOrOnePerLine
is set.
llvm-svn: 251406
Summary:
If this option is set, clang-format will always insert a line wrap, e.g.
before the first parameter of a function call unless all parameters fit
on the same line. This obviates the need to make a decision on the
alignment itself.
Use this style for Google's JavaScript style and add some minor tweaks
to correctly handle nested blocks etc. with it. Don't use this option
for for/while loops.
Reviewers: klimek
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D14104
llvm-svn: 251405
clang accepts both #include and #import for includes (the latter having an
implicit header guard). Let clang-format interleave both types if
--sort-includes is passed. #import is used frequently in Objective-C code.
http://reviews.llvm.org/D13853
llvm-svn: 250909
If a RegExp contains a character group with a quote (/["]/), the
trailing end of it is first tokenized as a string literal, which leads
to the merging code seeing an unbalanced bracket.
This change parses regex literals from the left hand side. That
simplifies the parsing code and also allows correctly handling escapes
and character classes, hopefully correctly parsing all regex literals.
Patch by Martin Probst, thank you.
Review: http://reviews.llvm.org/D13765
llvm-svn: 250648
Slashes in regular expressions do not need to be escaped and do not
terminate the regular expression even without a preceding backslash.
Patch by Martin Probst. Thank you.
llvm-svn: 250009
Fixes this bug: https://llvm.org/bugs/show_bug.cgi?id=24504
TokenAnnotator::spaceRequiredBetween was handling TT_ForEachMacro but
not TT_ObjCForIn, so lines that look like:
for (id nextObject in (NSArray *)myArray)
would incorrectly turn into:
for (id nextObject in(NSArray *)myArray)
Patch by Kent Sutherland, thank you.
llvm-svn: 249553
aligning assignments.
This was done correctly when aligning the declarations, but not when
aligning assignments.
FIXME: The code between assignments and declarations alignment is
roughly duplicated and
would benefit from factorization.
Bug 25090: https://llvm.org/bugs/show_bug.cgi?id=25090
Patch by Beren Minor. Thank you.
llvm-svn: 249552
This was made much easier by introducing an IncludeCategory struct to
replace the previously used std::pair.
Also, cleaned up documentation and added examples.
llvm-svn: 249392
This allows clang-format to align identifiers in consecutive
declarations. This is useful for increasing the readability of the code
in the same way the alignment of assignations is.
The code is a slightly modified version of the consecutive assignment
alignment code. Currently only the identifiers are aligned, and there is
no support of alignment of the pointer star or reference symbol.
The patch also solve the issue of alignments not being possible due to
the ColumnLimit for both the existing AlignConsecutiveAligments and the
new AlignConsecutiveDeclarations.
Patch by Beren Minor, thank you.
Review: http://reviews.llvm.org/D12362
llvm-svn: 248999
control the individual braces. The existing choices for brace wrapping
are now merely presets for the different flags that get expanded upon
calling the reformat function.
All presets have been chose to keep the existing formatting, so there
shouldn't be any difference in formatting behavior.
Also change the dump_format_style.py to properly document the nested
structs that are used to keep these flags discoverable among all the
configuration flags.
llvm-svn: 248802
Recognize the main module header as well as different #include categories.
This should now mimic the behavior of llvm/utils/sort_includes.py as
well as clang-tools-extra/clang-tidy/llvm/IncludeOrderCheck.cpp very
closely.
llvm-svn: 248782
JavaScript allows keywords to appear in IdenfierName positions, e.g.
fields, or object literal members, but not as plain identifiers.
Patch by Martin Probst. Thank you!
llvm-svn: 248714
To implement this nicely, add a function that merges two sets of
replacements that are meant to be done in sequence. This functionality
will also be useful for other applications, e.g. formatting the result
of clang-tidy fixes.
llvm-svn: 248367
It wasn't correctly handling this case:
int oneTwoThree = 123;
int oneTwo = 12;
method();
Review: http://reviews.llvm.org/D12369
Patch by Beren Minor. Thank you!
llvm-svn: 248254
Before:
DEPRECATED("Use NewClass::NewFunction instead.") int OldFunction(
const string ¶meter) {}
Could not be formatted at all, as clang-format would both require and
disallow the break before "int".
llvm-svn: 245846
This is a bit of a step back of what we did in r222531, as there are
some corner cases in C++, where this kind of formatting is really bad.
Example:
Before:
virtual aaaaaaaaaaaaaaaa(std::function<bool()> IsKindWeWant = [&]() {
return true;
}, aaaaa aaaaaaaaa);
After:
virtual aaaaaaaaaaaaaaaa(std::function<bool()> IsKindWeWant =
[&]() { return true; },
aaaaa aaaaaaaaa);
The block formatting logic in JavaScript will probably go some other changes,
too, and we'll potentially be able to make the rules more consistent again. For
now, this seems to be the best approach for C++.
llvm-svn: 245694
Summary:
Add brace style `BS_WebKit` as described on https://www.webkit.org/coding/coding-style.html:
* Function definitions: place each brace on its own line.
* Other braces: place the open brace on the line preceding the code block; place the close brace on its own line.
Set brace style used in `getWebKitStyle()` to the newly added `BS_WebKit`.
Reviewers: djasper, klimek
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D11837
llvm-svn: 244446
In proto, enum constants can contain complex options and should be
handled more like individual declarations.
Before:
enum Type {
UNKNOWN = 0 [(some_options) =
{
a: aa,
b: bb
}];
};
After:
enum Type {
UNKNOWN = 0 [(some_options) = {
a: aa,
b: bb
}];
};
llvm-svn: 242404
Before:
class Test {
aaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaa:
aaaaaaaaaaaaaaaaaaaaaaaa): aaaaaaaaaaaaaaaaaaaaaa {}
}
After:
class Test {
aaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaa: aaaaaaaaaaaaaaaaaaaaaaaa):
aaaaaaaaaaaaaaaaaaaaaa {}
}
llvm-svn: 241908
__attribute__ was treated as the name of a function definition, with the
tokens in parentheses being the parameter list. This formats incorrectly
with AlwaysBreakAfterDefinitionReturnType. Fix it by treating
__attribute__ like decltype.
Patch by Strager Neds, thank you.
llvm-svn: 241439
The MacroBlockBegin and MacroBlockEnd options make matching macro identifiers
behave like '{' and '}', respectively, in terms of indentation.
Mozilla code, for example, uses several macros that begin and end a scope.
Previously, Clang-Format removed the indentation resulting in:
MACRO_BEGIN(...)
MACRO_ENTRY(...)
MACRO_ENTRY(...)
MACRO_END
Now, using the options
MacroBlockBegin: "^[A-Z_]+_BEGIN$"
MacroBlockEnd: "^[A-Z_]+_END$"
will yield the expected result:
MACRO_BEGIN(...)
MACRO_ENTRY(...)
MACRO_ENTRY(...)
MACRO_END
Differential Revision: http://reviews.llvm.org/D10840
llvm-svn: 241363
Among other things, this makes clang-format understand arbitrary blocks
embedded in them, such as:
SomeFunction({MACRO({ return output; }), b});
where MACRO could e.g. expand to a lambda.
llvm-svn: 241059
Format @autoreleasepool properly for the Attach brace style
by recognizing @autoreleasepool as a block introducer.
Patch from Strager Neds!
http://reviews.llvm.org/D10372
llvm-svn: 240896
The patch is generated using this command:
$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
work/llvm/tools/clang
To reduce churn, not touching namespaces spanning less than 10 lines.
llvm-svn: 240270
conservative.
In particular, this fixes an unwanted corner case.
Before:
string s =
someFunction("aaaa"
"bbbb");
After:
string s = someFunction(
"aaaa"
"bbbb");
llvm-svn: 240129
It was a bit too aggressive.
With this patch, we keep on breaking here:
aaaaaaaaaaaaa(aaaaaaa,
"aaaaaaa"
"bbbbbbb");
But don't break in:
aaaaaaaaaaaaa(aaaaaaa, aaaaaaaa("aaaaaaa"
"bbbbbbb"));
llvm-svn: 240024
Before:
var func =
function() {
doSomething();
};
After:
var func =
function() {
doSomething();
};
This is a very narrow special case which fixes most of the discrepency
with what our users do. In the long run, we should try to come up with
a more generic fix for indenting these.
llvm-svn: 240014
In essence this is meant to consistently indent multiline strings by a
fixed amount of spaces from the start of the line. Don't do this in
cases where it wouldn't help anyway.
Before:
someFunction(aaaaa,
"aaaaa"
"bbbbb");
After:
someFunction(aaaaa, "aaaaa"
"bbbbb");
llvm-svn: 240004
This makes this consistent with non-typescript enums.
Also shuffle the language-dependent stuff in mustBreakBefore to a
single location.
Patch initiated by Martin Probst.
llvm-svn: 239894
Before, these would not properly detected because of the char/string
literal found when re-lexing after the first `:
var x = `'`; // comment with matching quote '
var x = `"`; // comment with matching quote "
llvm-svn: 239693
Before:
int c = []() -> int *{ return 2; }();
After:
int c = []() -> int * { return 2; }();
Based on patch by James Dennett (http://reviews.llvm.org/D10410), thank you!
llvm-svn: 239600
statement.
When an exported function would follow a class declaration, it would not
be recognized as a stand-alone function. That would then collapse the
following line with the current one, e.g.
class C {}
export function f() {} var x;
llvm-svn: 239592
In the long run, these two might be independent or we might to only
allow specific combinations. Until we have a corresponding request,
however, it is hard to do the right thing and choose the right
configuration options. Thus, just don't touch the options yet and
just modify the behavior slightly.
llvm-svn: 239531
The following example used to crash clang-format.
#define a\
/**/}
Adjusting the indentation level cache for the line starting with the
comment would lead to an out-of-bounds array read.
llvm-svn: 239521
Before clang-format would e.g. add a space into
#define Q_FOREACH(x, y)
which turns this into a non-function-like macro.
Patch by Strager Neds, thank you!
llvm-svn: 239513
assignments as enums.
Top level object literals are treated as enums, and their k/v pairs are put on
separate lines:
X.Y = {
A: 1,
B: 2
};
However assignments within blocks should not be affected:
function x() {
y = {a:1, b:2};
}
This change fixes the second case. Patch by Martin Probst.
llvm-svn: 239462
Before:
template <typename T>
auto aaaaaaaaaaaaaaaaaaaaaa(T t) -> decltype(eaaaaaaaaaaaaaaa<T>(t.a)
.aaaaaaaa());
After:
template <typename T>
auto aaaaaaaaaaaaaaaaaaaaaa(T t)
-> decltype(eaaaaaaaaaaaaaaa<T>(t.a).aaaaaaaa());
Also add a test case for a difficult template parsing case I stumbled accross.
Needs fixing.
llvm-svn: 239149
This is a more correct representation than using "Equality" introduced
in r238942 which was a quick fix to solve an actual regression.
According to the typescript spec, arrows behave like "low-precedence"
assignments.
Before:
var a = a.aaaaaaa((a: a) => aaaaaaaaaaaaaaaaaaaaa(bbbbbbbbb) &&
aaaaaaaaaaaaaaaaaaaaa(bbbbbbb));
After:
var a = a.aaaaaaa((a: a) => aaaaaaaaaaaaaaaaaaaaa(bbbbbbbbb) &&
aaaaaaaaaaaaaaaaaaaaa(bbbbbbb));
llvm-svn: 239137
Before:
var aaaaa: List<SomeThing> = [
new SomeThingAAAAAAAAAAAA(),
new SomeThingBBBBBBBBB()
];
After:
var aaaaa: List<SomeThing> =
[new SomeThingAAAAAAAAAAAA(), new SomeThingBBBBBBBBB()];
llvm-svn: 238909
Before:
someFunction(() =>
{
doSomething(); // break
})
.doSomethingElse( // break
);
After:
someFunction(() => {
doSomething(); // break
})
.doSomethingElse( // break
);
This is still bad, but at least it is consistent with what we do for other
function literals. Added corresponding tests.
llvm-svn: 238736
method expressions and array literals. They should not bind stronger
than regular parentheses or the braces of braced lists.
Specific test case in JavaScript:
Before:
var aaaaa: List<
SomeThing> = [new SomeThingAAAAAAAAAAAA(), new SomeThingBBBBBBBBB()];
After:
var aaaaa: List<SomeThing> = [
new SomeThingAAAAAAAAAAAA(),
new SomeThingBBBBBBBBB()
];
llvm-svn: 238400
A definintion like this could not be formatted at all:
constructor({aa}: {
aa?: string,
aaaaaaaa?: string,
aaaaaaaaaaaaaaa?: boolean,
aaaaaa?: List<string>
}) {
}
llvm-svn: 238291
instead of BinPackParameters. Braced lists are used as constructor
calls in many places and so the bin-packing should follow what is done
for other calls and not what is done for function declarations.
llvm-svn: 238184
Specifically, don't add a space before it.
Before:
someFunction(... a);
var x = [1, 2, ... a];
After:
someFunction(...a);
var x = [1, 2, ...a];
llvm-svn: 238183
This fixes a case where the column limit was incorrectly calculated
leading to a macro like this:
#define A \
[] { \
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx( \
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx); \
}
exceeding the column limit.
llvm-svn: 238182
Assigns a token type (TT_JsFatArrow) to => tokens, and uses that to
more easily recognize and format fat arrow functions.
Improves function parsing to better recognize formal parameter
lists and return type declarations.
Recognizes arrow functions and parse function bodies as child blocks.
Patch by Martin Probst.
llvm-svn: 237895
"void (*my_function)(void)" should become "void (*my_function) (void)" when
SpaceBeforeParens is set to 'Always'
Differential Revision: http://reviews.llvm.org/D9835
llvm-svn: 237704
Before:
for (SmallVectorImpl<TemplateIdAnnotationn *>::iterator I =
Container.begin(),
E = Container.end();
I != E; ++I)
After:
for (SmallVectorImpl<TemplateIdAnnotationn *>::iterator
I = Container.begin(),
E = Container.end();
I != E; ++I)
This fixes llvm.org/PR23544.
llvm-svn: 237688
Before:
[call aaaaaaaa.aaaaaaaa.aaaaaaaa.aaaaaaaa.aaaaaaaa.aaaaaaaa.aaaaaaaa.aaaaaaaa.
aaaaaaaa];
After:
[call aaaaaaaa.aaaaaaaa.aaaaaaaa.aaaaaaaa.aaaaaaaa.aaaaaaaa.aaaaaaaa.aaaaaaaa
.aaaaaaaa];
This merely papers over the fact that we aren't parsing ObjC method calls
correctly. Also, the indentation is weird.
llvm-svn: 237681
Before:
class C : test {
class D : test{void f(){int i{2};
}
}
;
}
;
After:
class C : test {
class D : test {
void f() { int i{2}; }
};
};
llvm-svn: 237569
Before:
ASSERT("aaaaaaaaaaaaaaa")
<< aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
<< bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb;
After:
ASSERT("aaaaaaaaaaaaaaa") << aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
<< bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb;
Also cleanup implementation a bit and only mark closing parenthesis of
these annotations.
llvm-svn: 237567
Generally, clang-format tries to keep label-value pairs on a single
line for stream operators. However, we should not do that if there is
just a single such pair, as that doesn't help much.
Before:
llvm::errs() << "aaaaaaaaaaaa: " << aaaaaaa(aaaaaaaaa,
aaaaaaaaa);
After:
llvm::errs() << "aaaaaaaaaaaa: "
<< aaaaaaa(aaaaaaaaa, aaaaaaaaa);
Also remove old test case that was testing actual behavior any more.
llvm-svn: 237535
comments. At some point, we might to want to a layout with a different
number of columns instead, but at the moment, this causes more
confusion than it's worth.
llvm-svn: 237427
before binary/ternary operators.
Basically, it doesn't seem right to indent a nested block aligned to a
binary or ternary operator.
Before:
int i = aaaaaa ? 1 //
: [] {
return 2; //
}();
llvm::errs() << "number of twos is "
<< std::count_if(v.begin(), v.end(), [](int x) {
return x == 2; // force break
});
After:
int i = aaaaaa ? 1 //
: [] {
return 2; //
}();
llvm::errs() << "number of twos is "
<< std::count_if(v.begin(), v.end(), [](int x) {
return x == 2; // force break
});
llvm-svn: 237263
Summary:
a) Pull out a class LevelIndentTracker whose responsibility is to keep track
of the indent of levels across multiple annotated lines.
b) Put all responsibility for merging lines into the LineJoiner; make the
LineJoiner iterate over the lines so we never operate on a line that might
be merged later; this makes the interface safer to use.
c) Move formatting of the end-of-file whitespace into formatFirstToken.
Fix bugs that became obvious after the refactoring:
1. We would not format lines with offsets correctly inside nested blocks if
only the outer expression was affected:
int x = s({ // clang-format only this line
class X {
public:
// ^ this starts at the non-modified indnent level; previously we would
// not fix this, now we correctly outdent it.
void f();
};
});
2. We would incorrectly align comments across lines that do not have comments
for lines with nested blocks:
int expression; // with comment
int x = s({
int y; // comment
int z; // we would incorrectly align this comment with the comment on
// 'expression'
});
llvm-svn: 237104
Specifically, calculate the deviation between the shortest and longest
element (which is used to prevent excessive whitespace) per column, not
overall. This automatically handles the corner cases of a single column
and a single row so that the actualy implementation becomes simpler.
Before:
vector<int> x = {1,
aaaaaaaaaaaaaaaaaaaaaa,
2,
bbbbbbbbbbbbbbbbbbbbbb,
3,
cccccccccccccccccccccc};
After:
vector<int> x = {1, aaaaaaaaaaaaaaaaaaaaaa,
2, bbbbbbbbbbbbbbbbbbbbbb,
3, cccccccccccccccccccccc};
llvm-svn: 236992
Some compilers ignore everything after a semicolon in such inline asm
blocks and thus, the closing brace must not be moved to the previous
line.
llvm-svn: 236946
In particular:
* If the difference between the longest and shortest element, we copped
out of column format completely. Now, we instead allow to arrange
these in a single column, essentially enforcing a one-per-line format.
* Allow column layout even if there are braced lists. Especially, if
there are many short lists, this can be beneficial. The bad case,
where there is a long nested init list is usually caught as we now
limit the length difference of the longest and shortest element.
llvm-svn: 236851
Before:
[aaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaa:
aaaaaaaa aaa:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa];
After:
[aaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaa:aaaaaaaa
aaa:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa];
Note that this might now violate the column limit and we probably need an
alternative way of indenting these then. However, that is still strictly better
than the messy formatting that clang-format did before.
llvm-svn: 236598
In the process, fix an old todo that I don't really know how to write
tests for. The problem is that Clang's lexer creates very strange token
sequences for these. However, the new approach seems generally better
and easier to read so I am submitting it nonetheless.
llvm-svn: 236589
Splitting:
/**
* multiline block comment
*
*/
Before:
/**
* multiline block
*comment
*
*/
After:
/**
* multiline block
* comment
*
*/
The reason was that the empty line inside the comment (with just the "*") was
confusing the comment breaking logic.
llvm-svn: 236573
Optional methods use ? tokens like this:
interface X { y?(): z; }
It seems easiest to detect and disambiguate these from ternary
expressions by checking if the code is in a declaration context. Turns
out that that didn't quite work properly for interfaces in Java and JS,
and for JS file root contexts.
Patch by Martin Probst, thank you.
llvm-svn: 236488
OriginalColumn might not be set, so fall back to Location and SourceMgr
in case it is missing. Also initialize end column in case the token is
multi line, but it's the ` token itself that starts the multi line.
Patch by Martin Probst, thank you!
llvm-svn: 236383
Parameters can have templated types and default values (= ...), which is
another location in which a template closer should be followed by
whitespace.
Patch by Martin Probst, thank you.
llvm-svn: 236382
In Objective-C some style guides use a style where assignment operators are
aligned, in an effort to increase code readability. This patch adds an option
to the format library which allows this functionality. It is disabled by
default for all the included styles, so it must be explicitly enabled.
The option will change code such as:
- (void)method {
NSNumber *one = @1;
NSNumber *twentyFive = @25;
}
to:
- (void)method {
NSNumber *one = @1;
NSNumber *twentyFive = @25;
}
Patch by Matt Oakes. Thank you!
Accidentally reformatted all the tests...
llvm-svn: 236100
This is now obvious as the pointer alignment behavior was changed.
Before (even with pointer alignment "Left"):
MACRO Constructor(const int &i) : a(a), b(b) {}
After:
MACRO Constructor(const int& i) : a(a), b(b) {}
llvm-svn: 235301
spacing also fixed by r230473.
The fix in r230473 was done to enable fixing the spacing for
std::function<void( int, int )>.
I did not realized that it also fixed this
issue. Since it is fairly different from
Deleted &operator=(const Deleted &)& = default;
fixed in r230473, it seems sensible to add the regression test for it.
Also cleaned up the test by removing duplicated code and comment, and kept
repeated test set consistent.
Result of running the new tests with r230473 backed out:
[ RUN ] FormatTest.ConfigurableSpacesInParentheses
Actual: "std::function<void(int, int)> callback;"
Expected: "std::function<void( int, int )> callback;"
Actual: "std::function<void( int, int )> callback;"
Expected: "std::function<void(int, int)> callback;"
Actual: "std::function<void( int, int ) > callback;"
Expected: "std::function<void(int, int)> callback;"
[ FAILED ] FormatTest.ConfigurableSpacesInParentheses (402 ms)
Result of new tests with r230473:
[ RUN ] FormatTest.ConfigurableSpacesInParentheses
[ OK ] FormatTest.ConfigurableSpacesInParentheses (209 ms)
Review: http://reviews.llvm.org/D7922
Patch by Jean-Philippe Dufraigne. Thanks!
llvm-svn: 232632
The current enum detection is overly aggressive. As NestingLevel only
applies per line (?) it classifies many if not most object literals as
enum declarations and adds superfluous line breaks into them. This
change narrows the heuristic by requiring an assignment just before the
open brace and requiring the line to start with an identifier.
Patch by Martin Probst. Thank you.
llvm-svn: 232320
Before:
A a = new A(){public String toString(){return "NotReallyA";
}
}
;
After:
A a = return new A() {
public String toString() {
return "NotReallyA";
}
};
This fixes llvm.org/PR22878.
llvm-svn: 232042
There was already a TODO to double-check whether the extra indenation
makes sense. A slightly different case reveals that it is actively harmful:
for (int i = 0; i < aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ||
bbbbbbbbbbbbbbbbbbbb < ccccccccccccccc;
++i) {
}
Here (and it is probably not a totally infrequent case, it just works out that
"i < " is four spaces and so the four space extra indentation makes the
operator precedence confusing. So, this will now instead be formatted
as:
for (int i = 0; i < aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ||
bbbbbbbbbbbbbbbbbbbb < ccccccccccccccc;
++i) {
}
llvm-svn: 231461
With incomplete code, we aren't guaranteed to generated changes for
every token. In that case, we need to assume that even the very first
change can continue a preprocessor directive and initialize values
accordingly.
llvm-svn: 231066
Seems like the most consistent thing to do and in multi-var DeclStmts,
it is especially important to point out that the */& bind to the
identifier.
llvm-svn: 230903
Before:
Aaaa aaaaaaaaaaa{
{
a, // +1 indent weird.
b, // trailing comma signals one per line.
}, // trailing comma signals one per line.
};
After:
Aaaa aaaaaaaaaaa{
{
a, // better!?
b, // trailing comma signals one per line.
}, // trailing comma signals one per line.
};
Interesting that this apparently was entirely untested :-(.
llvm-svn: 230627
This adds support for JavaScript class definitions (again following
TypeScript & AtScript style). This only required support for
visibility modifiers in JS, everything else was already working.
Patch by Martin Probst, thank you.
llvm-svn: 229701
This patch adds support for type annotations that follow TypeScript's,
Flow's, and AtScript's syntax style.
Patch by Martin Probst, thank you.
Review: http://reviews.llvm.org/D7721
llvm-svn: 229700
This prevents contracting:
auto lambda = []() {
int a = 2
#if A
+ 2
#endif
;
};
into:
auto lambda = []() { int a = 2
#if A + 2
#endif ; };
Which is obviously BAD.
This fixes llvm.org/PR22496.
llvm-svn: 228522
Before:
@try {
// ...
}
@finally {
// ...
}
Now:
@try {
// ...
} @finally {
// ...
}
This is consistent with how we format C++ try blocks and SEH try blocks.
clang-format not doing this before was an implementation oversight.
This is dependent on BraceBreakingStyle. The snippet above is with the
Attach style. Style Stroustrip for example still results in the "Before:"
snippet, which makes sense since other blocks (try, else) break after '}' too.
llvm-svn: 228483
This lets clang-format format
__try {
} __except(0) {
}
and
__try {
} __finally {
}
correctly. __try and __finally are keywords if `LangOpts.MicrosoftExt` is set,
so this turns this on. This also enables a few other keywords, but it
shouldn't overly perturb regular clang-format operation. __except is a
context-sensitive keyword, so `AdditionalKeywords` needs to be passed around to
a few more places.
Fixes PR22321.
llvm-svn: 228148
We did't properly mark all of an AnnotatedLine's children as finalized
and thus would reformat the same tokens in different branches of #if/#else
sequences leading to invalid replacements.
llvm-svn: 226930
Specifically, adjust the leading "__asm {" and trailing "}" while still
leaving the assembly inside it alone.
This fixes llvm.org/PR22190.
llvm-svn: 225623
This makes piped output easier to read in many instances.
Before:
llvm::errs() << aaaa << std::endl << bbbb << std::endl;
After:
llvm::errs() << aaaa << std::endl
<< bbbb << std::endl;
Also fix a few instance of "don't use else after return" as per the
coding standards.
llvm-svn: 225444
This prevents clang-format from moving/aligning the comment in the
snippet:
void f() {
int i; // some comment
// some unrelated comment
}
llvm-svn: 225352
The proper way to break string literals in these languages is by inserting a "+"
between parts which we don't support yet. So we disable string literal breaking
until then.
llvm-svn: 224120
This only applies when not aligning after the return itself (which is
commonly done for C++.
Before:
return aaaaaaaaaa
? bbbbbbbbbb(
bbbbbb) // This is indented relative to aaaaaaaaaa.
: b;
After:
return aaaaaaaaaa
? bbbbbbbbbb(
bbbbbb)
: b;
llvm-svn: 223694
Uncovered by a Java test case:
Before:
public some.package.Type someFunction( // comment
int parameter) {}
After:
public some.package.Type someFunction( // comment
int parameter) {}
llvm-svn: 223228
With alignment:
int aaaaaa = aa
+ bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
* cccccccccccccccccccccccccccccccc;
Without alignment:
int aaaaaa = aa
+ bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
* cccccccccccccccccccccccccccccccc;
This fixes llvm.org/PR21666.
llvm-svn: 223117
Francois Ferrand