Before:
export abstract class X {y: number;}
(and all sorts of other havoc in more complicated cases).
After:
export abstract class X { y: number; }
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@257451 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@251690 91177308-0d34-0410-b5e6-96231b3b80d8
Before:
inline A operator^(const A &lhs, const A &rhs) {} int i;
After:
inline A operator^(const A &lhs, const A &rhs) {}
int i;
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249517 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248802 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@248714 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241363 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241059 91177308-0d34-0410-b5e6-96231b3b80d8
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;
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239592 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239149 91177308-0d34-0410-b5e6-96231b3b80d8
Specifically adhere to LLVM Coding Standards (no 'else' after
return/break/continue) and remove yet another implementation of
paren counting. We already have enough of those in the
UnwrappedLineParser.
No functional changes intended.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@238672 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@237895 91177308-0d34-0410-b5e6-96231b3b80d8
Before:
class C : test {
class D : test{void f(){int i{2};
}
}
;
}
;
After:
class C : test {
class D : test {
void f() { int i{2}; }
};
};
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@237569 91177308-0d34-0410-b5e6-96231b3b80d8
It was fooled by the comment.
Before:
SOME_UNRELATED_MACRO
/*static*/ int i;
After:
SOME_UNRELATED_MACRO
/*static*/ int i;
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@237246 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236946 91177308-0d34-0410-b5e6-96231b3b80d8
E.g.:
default:;
This can be used to get around restrictions as to what can follow a
label. It fixes llvm.org/PR19648.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236604 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@236488 91177308-0d34-0410-b5e6-96231b3b80d8
Daniel Jasper