Summary:
https://bugs.llvm.org/show_bug.cgi?id=42417
This revision removes the extra space between the opertor-> and the parens ()
```
class Bug {
auto operator-> () -> int*;
auto operator++(int) -> int;
};
```
Reviewers: klimek, owenpan, byoungyoung, mitchell-stellar
Reviewed By: mitchell-stellar
Subscribers: cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D68242
llvm-svn: 373746
Summary:
Change the BraceWrappingFlags' AfterControlStatement from a bool to an enum with three values:
* "Never": This is the default, and does not do any brace wrapping after control statements.
* "MultiLine": This only wraps braces after multi-line control statements (this really only happens when a ColumnLimit is specified).
* "Always": This always wraps braces after control statements.
The first and last options are backwards-compatible with "false" and "true", respectively.
The new "MultiLine" option is useful for when a wrapped control statement's indentation matches the subsequent block's indentation. It makes it easier to see at a glance where the control statement ends and where the block's code begins. For example:
```
if (
foo
&& bar )
{
baz();
}
```
vs.
```
if (
foo
&& bar ) {
baz();
}
```
Short control statements (1 line) do not wrap the brace to the next line, e.g.
```
if (foo) {
bar();
} else {
baz();
}
```
Reviewers: sammccall, owenpan, reuk, MyDeveloperDay, klimek
Reviewed By: MyDeveloperDay
Subscribers: MyDeveloperDay, cfe-commits
Patch By: mitchell-stellar
Tags: #clang-format, #clang, #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D68296
llvm-svn: 373647
Summary:
The historical context:
- clang-format was written when C++11 was current,
and the main language-version concern was >> vs > > template-closers.
An option was added to allow selection of the 03/11 behavior, or auto-detection.
- there was no option to choose simply "latest standard" so anyone who didn't
ever want 03 behavior or auto-detection specified Cpp11.
- In r185149 this option started to affect lexer mode.
- no options were added to cover c++14, as parsing/formatting
didn't change that much. The usage of Cpp11 to mean "latest" became
codified e.g. in r206263
- c++17 added some new constructs. These were mostly backwards-compatible and so
not used in old programs, so having no way to turn them off was OK.
- c++20 added some new constructs and keywords (e.g. co_*) that changed the
meaning of existing programs, and people started to complain that
the c++20 parsing couldn't be turned off.
New plan:
- Default ('Auto') behavior remains unchanged: parse as latest, format
template-closers based on input.
- Add new 'Latest' option that more clearly expresses the intent "use
modern features" that many projects have chosen for their .clang-format files.
- Allow pinning to *any* language version, using the same name as clang -std:
c++03, c++11, c++14 etc. These set precise lexer options, and any
clang-format code depending on these can use a >= check.
- For backwards compatibility, `Cpp11` is an alias for `Latest`, not `c++11`.
This matches the historical documented semantics of this option.
This spelling (and `Cpp03`) are deprecated.
Reviewers: klimek, modocache
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67541
llvm-svn: 373439
Summary:
The following code
```
struct f {
template <class T>
void bar() && noexcept {}
};
```
will be formatted to the following with LLVM style, and
`AlwaysBreakTemplateDeclarations: Yes`
```
struct f {
template <class T>
void bar() && noexcept {}
};
```
The indentation of the `void bar()` line is wrong.
Reviewers: klimek, owenpan, krasimir, timwoj, MyDeveloperDay
Reviewed By: klimek, MyDeveloperDay
Subscribers: MyDeveloperDay, ilya-biryukov, llvm-commits, cfe-commits
Patch By: AndWass
Tags: #clang-format, #clang, #llvm
Differential Revision: https://reviews.llvm.org/D68072
llvm-svn: 373165
The following code
```
struct f {
template <class T>
void bar() && noexcept {}
};
```
will be formatted to the following with LLVM style, and
`AlwaysBreakTemplateDeclarations: Yes`
```
struct f {
template <class T>
void bar() && noexcept {}
};
```
The indentation of the `void bar()` line is wrong.
Patch by Andreas Wass (AndWass)!
Differential Revision: https://reviews.llvm.org/D68072
llvm-svn: 373056
Summary:
It is annoying that the clang-format tests aren't themselves clang-formatted, if you use a format on save option in VS or vim this file gets massively changed then you have to `git difftool` all the other changes back out, which is risky.
I know people don't like mass clang-format changes but sometimes it becomes unmanageable to not. There are no other changes here other than just the reformat.
clang-format tests all pass.
```
[==========] 691 tests from 21 test cases ran. (55990 ms total)
[ PASSED ] 691 tests.
```
Reviewers: klimek, owenpan, timwoj
Reviewed By: owenpan
Subscribers: cfe-commits
Tags: #clang-tools-extra, #clang
Differential Revision: https://reviews.llvm.org/D67888
llvm-svn: 372689
Summary:
This patch adds support for the Whitesmiths indentation style to clang-format. It’s an update to a patch submitted in 2015 (D6833), but reworks it to use the newer API.
There are still some issues with this patch, primarily around `switch` and `case` support. The added unit test won’t currently pass because of the remaining issues.
Reviewers: mboehme, MyDeveloperDay, djasper
Reviewed By: MyDeveloperDay
Subscribers: krasimir, MyDeveloperDay, echristo, cfe-commits
Patch By: @timwoj (Tim Wojtulewicz)
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67627
llvm-svn: 372497
Summary:
https://bugs.llvm.org/show_bug.cgi?id=41899
```auto lambda = [&a = a]() { a = 2; };```
is formatted as
```auto lambda = [& a = a]() { a = 2; };```
With an extra space if PointerAlignment is set to Left
> The space "& a" looks strange when there is no type in the lambda's intializer expression. This can be worked around with by setting "PointerAlignment: Right", but ideally "PointerAlignment: Left" would not add a space in this case.
Reviewers: klimek, owenpan, krasimir, timwoj
Reviewed By: klimek
Subscribers: cfe-commits
Tags: #clang-tools-extra, #clang
Differential Revision: https://reviews.llvm.org/D67718
llvm-svn: 372249
This patch makes cases work where the lambda's template list doesn't
contain any of + - ! ~ / % << | || && ^ == != >= <= ? : true false
(see added FIXME).
Ports r359967 to clang-format.
Differential Revision: https://reviews.llvm.org/D67246
llvm-svn: 371854
Summary:
This option determines whether goto labels are indented according to scope. Setting this option to false causes goto labels to be flushed to the left.
This is mostly copied from [[ http://lists.llvm.org/pipermail/cfe-dev/2015-September/045014.html | this patch ]] submitted by Christian Neukirchen that didn't make its way into trunk.
```
true: false:
int f() { vs. int f() {
if (foo()) { if (foo()) {
label1: label1:
bar(); bar();
} }
label2: label2:
return 1; return 1;
} }
```
Reviewers: klimek, MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: cfe-commits
Tags: #clang, #clang-tools-extra
Patch by: tetsuo-cpp
Differential Revision: https://reviews.llvm.org/D67037
llvm-svn: 371719
Summary:
This (invalid) fragment is crashing clang-format:
```
#if 1
int x;
#elif
int y;
#endif
```
The reason being that the parser expects a token after `#elif`, and the
subsequent parsing of the next line does not check if `CurrentToken` is null.
Reviewers: gribozavr
Reviewed By: gribozavr
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D65940
llvm-svn: 368280
This is like r305666 (which added support for `if constexpr`) except
that it allows a macro name after the if.
This is slightly tricky for two reasons:
1. r305666 didn't add test coverage for all cases where it added a
kw_constexpr, so I had to figure out what all the added cases were
for. I now added tests for all `if constexpr` bits that didn't have
tests. (This took a while, see e.g. https://reviews.llvm.org/D65223)
2. Parsing `if <ident> (` as an if means that `#if defined(` and
`#if __has_include(` parse as ifs too. Add some special-case code
to prevent this from happening where it's incorrect.
Fixes PR39248.
Differential Revision: https://reviews.llvm.org/D65227
llvm-svn: 367167
Summary:
Previously, clang-format detected something like the following as a C++11 attribute specifier.
@[[NSArray class]]
instead of an array with an Objective-C method call inside. In general, when the attribute specifier checking runs, if it sees 2 identifiers in a row, it decides that the square brackets represent an Objective-C method call. However, here, `class` is tokenized as a keyword instead of an identifier, so this check fails.
To fix this, the attribute specifier first checks whether the first square bracket has an "@" before it. If it does, then that square bracket is not the start of a attribute specifier because it is an Objective-C array literal. (The assumption is that @[[.*]] is not valid C/C++.)
Contributed by rkgibson2.
Reviewers: benhamilton
Reviewed By: benhamilton
Subscribers: aaron.ballman, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64632
llvm-svn: 366267
This option behaves similarly to AlignConsecutiveDeclarations and
AlignConsecutiveAssignments, aligning the assignment of C/C++
preprocessor macros on consecutive lines.
I've worked in many projects (embedded, mostly) where header files full
of large, well-aligned "#define" blocks are a common pattern. We
normally avoid using clang-format on these files, since it ruins any
existing alignment in said blocks. This style option will align "simple"
PP macros (no parameters) and PP macros with parameter lists on
consecutive lines.
Related Bugzilla entry (thanks mcuddie):
https://llvm.org/bugs/show_bug.cgi?id=20637
Patch by Nick Renieris (VelocityRa)!
Differential Revision: https://reviews.llvm.org/D28462
llvm-svn: 364938
Summary:
Other macros are used to declare namespaces, and should thus be handled
similarly. This is the case for crpcut's TESTSUITE macro, or for
unittest-cpp's SUITE macro:
TESTSUITE(Foo) {
TEST(MyFirstTest) {
assert(0);
}
} // TESTSUITE(Foo)
This patch deals with this cases by introducing a new option to specify
lists of namespace macros. Internally, it re-uses the system already in
place for foreach and statement macros, to ensure there is no impact on
performance.
Reviewers: krasimir, djasper, klimek
Reviewed By: klimek
Subscribers: acoomans, cfe-commits, klimek
Tags: #clang
Differential Revision: https://reviews.llvm.org/D37813
llvm-svn: 362740
Summary:
Adds a `TypenameMacros` configuration option that causes certain identifiers to be handled in a way similar to `typeof()`.
This is enough to:
- Prevent misinterpreting declarations of pointers to such types as expressions (`STACK_OF(int) * foo` -> `STACK_OF(int) *foo`),
- Avoid surprising line breaks in variable/struct field declarations (`STACK_OF(int)\nfoo;` -> `STACK_OF(int) foo;`, see https://bugs.llvm.org/show_bug.cgi?id=30353).
Reviewers: Typz, krasimir, djasper
Reviewed By: Typz
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57184
llvm-svn: 361986
Summary:
Addresses https://bugs.llvm.org/show_bug.cgi?id=41170
The AlwaysBreakAfterReturn type setting can go wrong if the line ends with a comment
```
void foo() /* comment */
```
or
```
void foo() // comment
```
It will incorrectly see such functions as Declarations and not Definitions
The following code addresses this by looking for function which end with `; <comment>` rather than just `;` or `<comment>`
Reviewers: klimek, djasper, reuk, russellmcc, owenpan, sammccall
Reviewed By: owenpan
Subscribers: lebedev.ri, cfe-commits, sammccall
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60363
llvm-svn: 358375
Summary:
Addresses PR40696 - https://bugs.llvm.org/show_bug.cgi?id=40696
The BreakAfterReturnType didn't work if it had a single arguments which was a template with an integer template parameter
```
int foo(A<8> a) { return a; }
```
When run with the Mozilla style. would not break after the `int`
```
int TestFn(A<8> a)
{
return a;
}
```
This revision resolves this issue by allowing numeric constants to be considered function parameters if if seen inside `<>`
Reviewers: djasper, klimek, JonasToth, krasimir, reuk, alexfh
Reviewed By: klimek
Subscribers: cfe-commits, llvm-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D59309
llvm-svn: 357837
This patch aims to add support for the following rules from the JUCE coding standards:
- Always put a space before an open parenthesis that contains text - e.g. foo (123);
- Never put a space before an empty pair of open/close parenthesis - e.g. foo();
Patch by Reuben Thomas
Differential Revision: https://reviews.llvm.org/D55170
llvm-svn: 357344
Summary:
This option `AllowShortLambdasOnASingleLine` similar to the other `AllowShort*` options, but applied to C++ lambdas.
Reviewers: djasper, klimek
Reviewed By: klimek
Subscribers: MyDeveloperDay, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57687
llvm-svn: 357027
Summary:
Sometime after 6.0.0 and the current trunk 9.0.0 the following code would be considered as objective C and not C++
Reported by: https://twitter.com/mattgodbolt/status/1096188576503644160
$ clang-format.exe test.h
Configuration file(s) do(es) not support Objective-C: C:\clang\build\.clang-format
--- test.h --
```
std::vector<std::pair<std::string,std::string>> C;
void foo()
{
for (auto && [A,B] : C)
{
std::string D = A + B;
}
}
```
The following code fixes this issue of incorrect detection
Reviewers: djasper, klimek, JonasToth, reuk
Reviewed By: klimek
Subscribers: cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D59546
llvm-svn: 356575
rC355158 added an optional language parameter to getLLVMStyle(), but this parameter was not used in getPredefinedStyle(). Because unit tests directly specify the style, this codepath wasn't tested. Add an additional unit test for getStyle().
llvm-svn: 356099
Summary:
Addressing: PR25010 - https://bugs.llvm.org/show_bug.cgi?id=25010
Code like:
```
if(true) var++;
else {
var--;
}
```
is reformatted to be
```
if (true)
var++;
else {
var--;
}
```
Even when `AllowShortIfStatementsOnASingleLine` is true
The following revision comes from a +1'd suggestion in the PR to support AllowShortIfElseStatementsOnASingleLine
This suppresses the clause prevents the merging of the if when there is a compound else
Reviewers: klimek, djasper, JonasToth, alexfh, krasimir, reuk
Reviewed By: reuk
Subscribers: reuk, Higuoxing, jdoerfert, cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D59087
llvm-svn: 356031
Summary:
Addressing: PR25010 - https://bugs.llvm.org/show_bug.cgi?id=25010
Code like:
```
if(true) var++;
else {
var--;
}
```
is reformatted to be
```
if (true)
var++;
else {
var--;
}
```
Even when `AllowShortIfStatementsOnASingleLine` is true
The following revision comes from a +1'd suggestion in the PR to support AllowShortIfElseStatementsOnASingleLine
This suppresses the clause prevents the merging of the if when there is a compound else
Reviewers: klimek, djasper, JonasToth, alexfh, krasimir, reuk
Reviewed By: reuk
Subscribers: reuk, Higuoxing, jdoerfert, cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D59087
llvm-svn: 356029
