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
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
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
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
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
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
Previously a regex-literal containing "/*" would through clang-format
off, e.g.:
var regex = /\/*$/;
Would lead to none of the following code to be formatted.
llvm-svn: 220860
Before:
var regex = / a\//; int i;
After:
var regex = /a\//;
int i;
This required pushing the Lexer into its wrapper class and generating a
new one in this specific case. Otherwise, the sequence get lexed as a
//-comment. This is hacky, but I don't know a better way (short of
supporting regex literals in the Lexer).
Pushing the Lexer down seems to make all the call sites simpler.
llvm-svn: 217444
Before:
e&& e.SomeFunction();
After:
e && e.SomeFunction();
Yeah, this might be useful for C++, too, but it is not such a frequent
pattern there (plus the fix is much harder).
llvm-svn: 217237
This worked initially but was broken by r210887.
Before:
function outer1(a, b) {
function inner1(a, b) { return a; } inner1(a, b);
} function outer2(a, b) { function inner2(a, b) { return a; } inner2(a, b); }
After:
function outer1(a, b) {
function inner1(a, b) { return a; }
inner1(a, b);
}
function outer2(a, b) {
function inner2(a, b) { return a; }
inner2(a, b);
}
Thanks to Adam Strzelecki for working on this.
llvm-svn: 212038
Before (JavaScript example, but can extend to other languages):
return {
a: 'E',
b: function() {
return function() {
f(); // This is wrong.
};
}
};
After:
return {
a: 'E',
b: function() {
return function() {
f(); // This is better.
};
}
};
llvm-svn: 210334
Before:
var literal = 'hello ' + 'world';
After:
var literal = 'hello ' +
'world';
There is no reason to concatenated two string literals with a '+' unless
the line break is intended.
llvm-svn: 209413
If simple (one-statement) blocks can be inlined, the length needs to be
calculated correctly.
Before (in JavaScript but this also affects lambdas, etc.):
var x = {
valueOf: function() { return 1; }
};
After:
var x = {valueOf: function() { return 1; }};
llvm-svn: 209410
So that JS functions can also be merged into a single line.
Before:
var func = function() {
return 1;
};
After:
var func = function() { return 1; };
llvm-svn: 208176
Before:
goog.scope(function() {
var x = a.b;
var y = c.d;
}); // goog.scope
After:
goog.scope(function() {
var x = a.b;
var y = c.d;
}); // goog.scope
llvm-svn: 208088
definition below all of the header #include lines, clang edition.
If you want more details about this, you can see some of the commits to
Debug.h in LLVM recently. This is just the clang section of a cleanup
I've done for all uses of DEBUG_TYPE in LLVM.
llvm-svn: 206849
encodes the canonical rules for LLVM's style. I noticed this had drifted
quite a bit when cleaning up LLVM, so wanted to clean up Clang as well.
llvm-svn: 198686
Summary:
Allow predefined styles to define different options for different
languages so that one can run:
clang-format -style=google file1.cpp file2.js
or use a single .clang-format file with "BasedOnStyle: Google" for both c++ and
JS files.
Added Google style for JavaScript with "BreakBeforeTernaryOperators" set to
false.
Reviewers: djasper
Reviewed By: djasper
CC: cfe-commits, klimek
Differential Revision: http://llvm-reviews.chandlerc.com/D2364
llvm-svn: 196909
Daniel Jasper