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!
llvm-svn: 252690
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
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
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
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
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
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
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:
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
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
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.
llvm-svn: 239398
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
Richard Smith