Before:
MACRO(> );
After:
MACRO(>);
Not overly important, but easy and good for symmetry reasons :-).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@253669 91177308-0d34-0410-b5e6-96231b3b80d8
https://gcc.gnu.org/onlinedocs/gcc/Typeof.html
Differences from the GCC extension:
* __auto_type is also permitted in C++ (but only in places where
it could appear in C), allowing its use in headers that might
be shared across C and C++, or used from C++98
* __auto_type can be combined with a declarator, as with C++ auto
(for instance, "__auto_type *p")
* multiple variables can be declared in a single __auto_type
declaration, with the C++ semantics (the deduced type must be
the same in each case)
This patch also adds a missing restriction on applying typeof to
a bit-field, which GCC has historically rejected in C (due to
lack of clarity as to whether the operand should be promoted).
The same restriction also applies to __auto_type in C (in both
GCC and Clang).
This also fixes PR25449.
Patch by Nicholas Allegra!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@252690 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@251405 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@249553 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
Before:
SomeType MemberFunction(const Deleted &)&;
After:
SomeType MemberFunction(const Deleted &) &;
Seems to be much more common.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@245934 91177308-0d34-0410-b5e6-96231b3b80d8
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".
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@245846 91177308-0d34-0410-b5e6-96231b3b80d8
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++.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@245694 91177308-0d34-0410-b5e6-96231b3b80d8
Previously we would format
call(
p);
as
call(
p);
with MaxEmptyLinesToKeep == 0.
Now we format it as:
call(p);
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@243429 91177308-0d34-0410-b5e6-96231b3b80d8
__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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@241439 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239894 91177308-0d34-0410-b5e6-96231b3b80d8
starts with a given sequence of tokens. Only the one-token version is
used yet, but other usages are coming up momentarily.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239892 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239462 91177308-0d34-0410-b5e6-96231b3b80d8
I have not succeeded in writing a proper test case for this yet and we
also need to solve the underlying fundamental problem of trying too
many combinations with nested blocks (basically this somewhat works
around our Dijkstra algorithm). Preventing this linebreak is good
anyways as usually the penalties never make us choose it (that's why I
can't create a test) and it also looks ugly.
Also cleaned up state comparison code that I discovered while hunting
this down.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239398 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
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));
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@239137 91177308-0d34-0410-b5e6-96231b3b80d8
Daniel Jasper