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
The main motivation behind this is to cleanup the WhitespaceManager and
make it more extensible for future alignment etc. features.
Specifically, WhitespaceManager has started to copy more and more code
that is already present in FormatToken. Instead, I think it makes more
sense to actually store a reference to each FormatToken for each change.
This has as a consequence led to a change in the calculation of indent
levels. Now, we actually compute them for each Token ahead of time,
which should be more efficient as it removes an unsigned value for the
ParenState, which is used during the combinatorial exploration of the
solution space.
No functional changes intended.
Review: https://reviews.llvm.org/D29300
llvm-svn: 293616
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
Chromium is starting to use clang-format on more JavaScript.
In doing this, we discovered that our defaults were not doing a good job
differentiating between JS and C++.
This change moves some defaults to only apply to C++.
https://reviews.llvm.org/D28165
Patch from Dan Beam <dbeam@chromium.org>!
llvm-svn: 290930
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
Summary:
Defining DEBUG_TYPE in a header file doesn't make sense.
It is already defined in the corresponding source file.
Reviewers: klimek, ioeric
Subscribers: klimek
Differential Revision: https://reviews.llvm.org/D27164
llvm-svn: 288125
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
In Format, remove the reformat() and clean() functions taking a SourceManager
and a FileID. Keep the versions taking StringRef Code.
- there was duplicated functionality
- the FileID versions were harder to use
- the clean() version is dead code anyways
Patch by Krasimir Georgiev. Thank you.
llvm-svn: 286243
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:
Introduces a separate target for comment manipulation.
Currently, comment manipulation is in BreakableComment.cpp.
Towards implementing comment reflowing, we want to factor out the
comment-related functionality, so it can be reused.
Start simple by just moving out getLineCommentIndentPrefix.
Patch by Krasimir Georgiev!
Reviewers: djasper
Subscribers: klimek, beanz, mgorny, modocache
Differential Revision: https://reviews.llvm.org/D25725
llvm-svn: 284573
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
Summary:
This lets people link against LLVM and their own version of the UTF
library.
I determined this only affects llvm, clang, lld, and lldb by running
$ git grep -wl 'UTF[0-9]\+\|\bConvertUTF\bisLegalUTF\|getNumBytesFor' | cut -f 1 -d '/' | sort | uniq
clang
lld
lldb
llvm
Tested with
ninja lldb
ninja check-clang check-llvm check-lld
(ninja check-lldb doesn't complete for me with or without this patch.)
Reviewers: rnk
Subscribers: klimek, beanz, mgorny, llvm-commits
Differential Revision: https://reviews.llvm.org/D24996
llvm-svn: 282822
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: @returns is incorrect code, the standard is @return. However wrapping it can still confuse users.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D24767
llvm-svn: 282056
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
Krasimir Georgiev