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
Preparatory change for D65043.
We current use `!=LS_Cpp03` to enable language standards 11,14,17, and
2a. `>=LS_Cpp11` is better if we decide to add new LanguageStandard in
the future.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D65183
llvm-svn: 366876
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:
Top-level "package" and "import" statements should generally be kept on
one line, for all languages.
----
This reverts commit rL356912.
The regression from rL356835 was fixed via rC358275.
Reviewers: krasimir, sammccall, MyDeveloperDay, xinz, dchai, klimek
Reviewed By: krasimir, xinz, dchai
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60661
llvm-svn: 360411
Summary:
Currently clang-format uses ContinuationIndent to indent the contents of a raw
string literal that is the last parameter of the function call. This is to
achieve formatting similar to trailing:
```
f(1, 2, R"pb(
x: y)pb");
```
However this had the unfortunate consequence of producing format like this:
```
fffffff(1, 2,
R"pb(
a: b
)pb");
```
This patch makes clang-format consider indenting a trailing raw string param
after a newline based off the start of the format delimiter, producing:
```
fffffff(1, 2,
R"pb(
a: b
)pb");
```
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60558
llvm-svn: 358689
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:
AnnotatingParser::next() is needed to implicitly set TT_BlockComment
versus TT_LineComment. On most other paths through
AnnotatingParser::parseLine(), all tokens are consumed to achieve that.
This change updates one place where this wasn't done.
Contributed by @dchai!
Reviewers: krasimir
Reviewed By: krasimir
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60541
llvm-svn: 358275
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
Adding in androidx as another import group.
Differential Revision: https://reviews.llvm.org/D60203
Patch from Sam Maier <smaier@chromium.org>!
llvm-svn: 357700
Summary:
r357567 started to regroup include block for Google style; it was meant to apply
only for C++. This patch reverts this for ObjC.
Reviewers: ioeric
Reviewed By: ioeric
Subscribers: thakis, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60263
llvm-svn: 357695
Summary:
Currently clang-format would always emit a replacement for multi-block #include
sections if `IBS_Regroup`, even if the sections are correct:
```
% cat ~/test.h
#include <a.h>
#include "b.h"
% bin/clang-format --output-replacements-xml -style=google ~/test.h
<?xml version='1.0'?>
<replacements xml:space='preserve' incomplete_format='false'>
<replacement offset='0' length='30'>#include <a.h> #include "b.h"</replacement>
</replacements>
%
```
This change makes clang-format not emit replacements in this case.
The logic is similar to the one implemented for Java in r354452.
Reviewers: ioeric
Reviewed By: ioeric
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60199
llvm-svn: 357599
Summary:
Import sorting of java file, incorrectly move import statement to after a function beginning with the word import.
Make 1 character change to regular expression to ensure there is always at least one space/tab after the word import
Previously clang-format --style="LLVM" would format
```
import X;
class C {
void m() {
importFile();
}
}
```
as
```
class C {
void m() {
importFile();
import X;
}
}
```
Reviewers: djasper, klimek, reuk, JonasToth
Reviewed By: klimek
Subscribers: cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D59684
llvm-svn: 357345
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:
Revision r356575 had the unfortunate consequence that now clang-format never
detects an ObjC call expression after `&&`.
This patch tries harder to distinguish between C++17 structured bindings and
ObjC call expressions and adds a few regression tests.
Reviewers: klimek
Reviewed By: klimek
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59774
llvm-svn: 356928
This reverts commit r356835. This patch causes a regression, see the
test below:
verifyFormat("// Detached comment\n\n"
"// Leading comment\n"
"syntax = \"proto2\"; // trailing comment\n\n"
"// in foo.bar package\n"
"package foo.bar; // foo.bar package\n");
llvm-svn: 356912
Summary:
Top-level "package" and "import" statements should generally be kept on one
line, for all languages.
Reviewers: sammccall, krasimir, MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: MyDeveloperDay, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59627
Patch By: dchai (Donald Chai)
llvm-svn: 356835
Summary:
This revision adds basic support for formatting C# files with clang-format, I know the barrier to entry is high here so I'm sending this revision in to test the water as to whether this might be something we'd consider landing.
Tracking in Bugzilla as:
https://bugs.llvm.org/show_bug.cgi?id=40850
Justification:
C# code just looks ugly in comparison to the C++ code in our source tree which is clang-formatted.
I've struggled with Visual Studio reformatting to get a clean and consistent style, I want to format our C# code on saving like I do now for C++ and i want it to have the same style as defined in our .clang-format file, so it consistent as it can be with C++. (Braces/Breaking/Spaces/Indent etc..)
Using clang format without this patch leaves the code in a bad state, sometimes when the BreakStringLiterals is set, it fails to compile.
Mostly the C# is similar to Java, except instead of JavaAnnotations I try to reuse the TT_AttributeSquare.
Almost the most valuable portion is to have a new Language in order to partition the configuration for C# within a common .clang-format file, with the auto detection on the .cs extension. But there are other C# specific styles that could be added later if this is accepted. in particular how `{ set;get }` is formatted.
Reviewers: djasper, klimek, krasimir, benhamilton, JonasToth
Reviewed By: klimek
Subscribers: llvm-commits, mgorny, jdoerfert, cfe-commits
Tags: #clang, #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D58404
llvm-svn: 356662
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
Addresses PR40999 https://bugs.llvm.org/show_bug.cgi?id=40999
Private fields and methods in JavaScript would get incorrectly indented
(it sees them as preprocessor directives and hence left aligns them)
In this revision `#identifier` tokens `tok::hash->tok::identifier` are
merged into a single new token `tok::identifier` with the `#` contained
inside the TokenText.
Before:
```
class Example {
pub = 1;
static pub2 = "foo";
static #priv2 = "bar";
method() { this.#priv = 5; }
static staticMethod() {
switch (this.#priv) {
case '1':
break;
}
}
this.#privateMethod(); // infinite loop
}
static #staticPrivateMethod() {}
}
```
After this fix the code will be correctly indented
```
class Example {
pub = 1;
#priv = 2;
static pub2 = "foo";
static #priv2 = "bar";
method() { this.#priv = 5; }
static staticMethod() {
switch (this.#priv) {
case '1':
#priv = 3;
break;
}
}
#privateMethod() {
this.#privateMethod(); // infinite loop
}
static #staticPrivateMethod() {}
}
```
NOTE: There might be some JavaScript code out there which uses the C
processor to preprocess .js files
http://www.nongnu.org/espresso/js-cpp.html. It's not clear how this
revision or even private fields and methods would interact.
Patch originally by MyDeveloperDays (thanks!).
llvm-svn: 356449
Before:
const x = veryLongIdentifier
`hello`;
After:
const x =
veryLongIdentifier`hello`;
While it's allowed to have the template string and tag identifier
separated by a line break, currently the clang-format output is not
stable when a break is forced. Additionally, disallowing a line break
makes it clear that the identifier is actually a tag for a template
string.
Patch originally by mitchellwills (thanks!).
llvm-svn: 356447
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
Summary:
The revision r355434 had the unfortunate side-effect that it started to
recognize certain ObjC expressions with a call subexpression followed by a
`a->b` subexpression as C++ lambda expressions.
This patch adds a bit of logic to handle these cases and documents them in
tests.
The commented-out test cases in the new test suite are ones that were
problematic before r355434.
Reviewers: MyDeveloperDay, gribozavr
Reviewed By: MyDeveloperDay, gribozavr
Subscribers: MyDeveloperDay, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59210
llvm-svn: 355831
Summary:
A Lamdba with a return type template with a boolean literal (true,false) behaves differently to an integer literal
https://bugs.llvm.org/show_bug.cgi?id=40910
Reviewers: klimek, djasper, JonasToth, alexfh, krasimir, jkorous
Reviewed By: jkorous
Subscribers: jkorous, cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D58922
llvm-svn: 355450
A template specialization of a template foo<int N> can contain integer constants and a whole bunch of operators - e. g. foo< 1 ? !0 : (3+1)%4 >
Inspired by https://reviews.llvm.org/D58922
Differential Revision: https://reviews.llvm.org/D58934
llvm-svn: 355434
Summary:
If the clang-format on/off is in a /* comment */ then the sorting of headers is not ignored
PR40901 - https://bugs.llvm.org/show_bug.cgi?id=40901
Reviewers: djasper, klimek, JonasToth, krasimir, alexfh
Reviewed By: alexfh
Subscribers: alexfh, cfe-commits, llvm-commits
Tags: #clang, #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D58819
llvm-svn: 355266
Previously revisions commited non-clang-formatted changes to the Format library, this means submitting any revision e.g. {D55170} can cause additional whitespace changes to potentially be included in a revision.
Commit a non functional change using latest build Windows clang-format r351376 with no other changes, to remove these differences
All FormatTests
pass [==========] 652 tests from 20 test cases ran.
llvm-svn: 355182
Summary:
clang-formatting wants to add spaces around items in square braces, e.g. [1, 2] -> [ 1, 2 ]. Based on a quick check [1], it seems like most cases are using the [1, 2] format, so make that the consistent one.
[1] in llvm `.td` files, the regex `\[[^ ]` (bracket followed by not-a-space) shows up ~400 times, but `\[\s[^ ]` (bracket followed by one space and one not-a-space) shows up ~40 times => ~90% uses this format.
Reviewers: djasper, krasimir, MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: MyDeveloperDay, arphaman, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D55964
llvm-svn: 355158
Summary:
getLLVMStyle() sets the default style, but doesn't take the language as a parameter, so can't set default parameters when they differ from C++. This change adds LanguageKind as an input to getLLVMStyle so that we can start doing that.
See D55964 as a motivation for this, where we want Tablegen to be formatted differently than C++.
Reviewers: djasper, krasimir, MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: jdoerfert, MyDeveloperDay, kristina, cfe-commits, arphaman
Tags: #clang
Differential Revision: https://reviews.llvm.org/D56943
llvm-svn: 355123
Summary:
Currently clang-format would always emit a replacement for a block of Java imports even if it is correctly formatted:
```
% cat /tmp/Aggregator.java
import X;
% clang-format /tmp/Aggregator.java
import X;
% clang-format -output-replacements-xml /tmp/Aggregator.java
<?xml version='1.0'?>
<replacements xml:space='preserve' incomplete_format='false'>
<replacement offset='0' length='9'>import X;</replacement>
</replacements>
%
```
This change makes clang-format not emit replacements in this case. Note that
there is logic to not emit replacements in this case for C++.
Reviewers: ioeric
Reviewed By: ioeric
Subscribers: jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58436
llvm-svn: 354452
Trailing comments are not always aligned properly when UseTab is set to Always.
Consider:
int a; // x
int bbbbbbbb; // x
With .clang-format:
---
Language: Cpp
BasedOnStyle: LLVM
UseTab: Always
...
The trailing comments of this code block should be aligned, but aren't
To align the first trailing comment it needs to insert 8 spaces. This should be
one tab plus six spaces. It skips the logic of the first partial tab in
FirstTabWidth (=2) + Style.TabWidth (=8) <= Spaces (=8) and only inserts one
tab. Proposed fix and test is attached.
Patch by Hylke Kleve.
Differential revision: https://reviews.llvm.org/D57655
llvm-svn: 354183
Summary:
Currently, `UnwrappedLineParser` thinks an arrow token after
an ObjC method expression is a C++ lambda arrow, so it formats:
```
[foo bar]->baz
```
as:
```
[foo bar] -> baz
```
Because `UnwrappedLineParser` runs before `TokenAnnotator`, it can't
know if the arrow token is after an ObjC method expression or not.
This diff makes `TokenAnnotator` remove the TT_LambdaArrow on
the arrow token if it follows an ObjC method expression.
Test Plan: New test added. Ran test with:
% ninja FormatTests && ./tools/clang/unittests/Format/FormatTests
Confirmed test failed before diff and passed after diff.
Reviewers: krasimir, djasper, sammccall
Reviewed By: sammccall
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57923
llvm-svn: 353531
Summary:
From https://bugs.llvm.org/show_bug.cgi?id=40516
```
$ cat a.cpp
const NamespaceName::VeryLongClassName &NamespaceName::VeryLongClassName::myFunction() {
// do stuff
}
const NamespaceName::VeryLongClassName &NamespaceName::VeryLongClassName::operator++() {
// do stuff
}
$ ~/ll/build/opt/bin/clang-format -style=LLVM a.cpp
const NamespaceName::VeryLongClassName &
NamespaceName::VeryLongClassName::myFunction() {
// do stuff
}
const NamespaceName::VeryLongClassName &NamespaceName::VeryLongClassName::
operator++() {
// do stuff
}
```
What was happening is that the split penalty before `operator` was being set to
a smaller value by a prior if block. Moved checks around to fix this and added a
regression test.
Reviewers: djasper
Reviewed By: djasper
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57604
llvm-svn: 353033
The commit r322690 introduced support for ObjC detection in header files.
Unfortunately some C headers that use designated initializers are now
incorrectly detected as Objective-C.
This commit fixes it by ensuring that `[ token ]` is not annotated as an
Objective-C message send.
rdar://45504376
Differential Revision: https://reviews.llvm.org/D56226
llvm-svn: 352125
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
Summary:
It's a new primitive for importing symbols, and should be treated like
the (previously handled) `goog.require` and `goog.forwardDeclare`.
Reviewers: krasimir
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D56385
llvm-svn: 350516
Summary:
r346756 refined clang-format to not treat the `[` in `asm (...: [] ..)` as an
ObjCExpr. However that's not enough, as we might have a comma-separated list of
such clobbers as in the newly added test.
This updates the detection to instead look at the Line's first token being `asm`
and not mark `[`-s as ObjCExprs in this case.
Reviewers: djasper, benhamilton
Reviewed By: djasper, benhamilton
Subscribers: benhamilton, cfe-commits
Differential Revision: https://reviews.llvm.org/D54795
llvm-svn: 347465
Summary:
Clang-format is treating all occurences of `is` in js as type matchers. In some
cases this is wrong, as it might be a dict key.
Reviewers: mprobst
Reviewed By: mprobst
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D54753
llvm-svn: 347307
Summary:
The opening square of an inline asm clobber was being annotated as an ObjCExpr.
This caused, amongst other things, the ObjCGuesser to guess header files
containing that pattern as ObjC files.
Reviewers: benhamilton
Reviewed By: benhamilton
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D54111
llvm-svn: 346756
Summary:
clang-format can get confused by string literals in TableGen: it knows that strings can be broken up, but doesn't seem to understand how that can be indented across line breaks, and arranges them in a weird triangular pattern. Take this output example from `clang-format tools/llvm-objcopy/ObjcopyOpts.td` (which has now been formatted in rL345896 with this patch applied):
```
defm keep_global_symbols
: Eq<
"keep-global-symbols", "Reads a list of symbols from <filename> and "
"runs as if " "--keep-global-symbol=<symbol> "
"is set for each one. "
"<filename> " "contains one "
"symbol per line "
"and may contain "
"comments "
"beginning " "with"
" '#'"
". "
"Lead"
"ing "
```
Reviewers: alexshap, MaskRay, djasper
Reviewed By: MaskRay
Subscribers: krasimir, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D53952
llvm-svn: 346687
Summary:
The issue is that for array subscript like:
```
arr[[Foo() bar]];
```
ClangFormat will recognize it as C++11 attribute syntax and put a space between 'arr' and first '[', like:
```
arr [[Foo() bar]];
```
Now it is fixed. Tested with:
```
ninja FormatTests
```
Reviewers: benhamilton
Reviewed By: benhamilton
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D54288
llvm-svn: 346566
Summary:
To handle diagnosing bugs where ObjCHeaderStyleGuesser guesses
wrong, this diff adds a bit more debug logging to the Objective-C
language guesser.
Reviewers: krasimir
Reviewed By: krasimir
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D54110
llvm-svn: 346144
Summary:
This is done in order to improve cases where the lambda's body is moved too far to the right. Consider the following snippet with column limit set to 79:
```
void f() {
leader::MakeThisCallHere(&leader_service_,
cq_.get(),
[this, liveness](const leader::ReadRecordReq& req,
std::function<void()> done) {
logger_->HandleReadRecord(
req, resp, std::move(done));
});
leader::MakeAnother(&leader_service_,
cq_.get(),
[this, liveness](const leader::ReadRecordReq& req,
std::function<void()> done) {
logger_->HandleReadRecord(
req, resp, std::move(done), a);
});
}
```
The tool favors extra indentation for the lambda body and so the code incurs extra wrapping and adjacent calls are indented to a different level. I find this behavior annoying and I'd like the tool to favor new lines and, thus, use the extra width.
The fix, reduced, brings the following formatting.
Before:
function(1,
[] {
DoStuff();
//
},
1);
After:
function(
1,
[] {
DoStuff();
//
},
1);
Refer to the new tests in FormatTest.cpp
Contributed by oleg.smolsky!
Reviewers: djasper, klimek, krasimir
Subscribers: cfe-commits, owenpan
Tags: #clang
Differential Revision: https://reviews.llvm.org/D52676
llvm-svn: 345753
We haven't supported compiling ObjC1 for a long time (and never will again), so
there isn't any reason to keep these separate. This patch replaces
LangOpts::ObjC1 and LangOpts::ObjC2 with LangOpts::ObjC.
Differential revision: https://reviews.llvm.org/D53547
llvm-svn: 345637
Summary:
Currently clang-format breaks before the next parameter after multiline parameters (also recursively for the parent expressions of multiline parameters). However, it fails to do so for formatted multiline raw string literals:
```
$ cat test.cc
// Examples
// Regular multiline tokens
int x = f(R"(multi
line)", 2);
}
int y = g(h(R"(multi
line)"), 2);
// Formatted multiline tokens
int z = f(R"pb(multi: 1 #
line: 2)pb", 2);
int w = g(h(R"pb(multi: 1 #
line: 2)pb"), 2);
$ clang-format -style=google test.cc
// Examples
// Regular multiline tokens
int x = f(R"(multi
line)",
2);
}
int y = g(h(R"(multi
line)"),
2);
// Formatted multiline tokens
int z = f(R"pb(multi: 1 #
line: 2)pb", 2);
int w = g(h(R"pb(multi: 1 #
line: 2)pb"), 2);
```
This patch addresses this inconsistency by forcing breaking after multiline formatted raw string literals. This requires a little tweak to the indentation chosen for the contents of a formatted raw string literal: in case when that's a parameter and not the last one, the indentation is based off of the uniform indentation of all of the parameters.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D52448
llvm-svn: 345242
Previously, Java annotation declarations (@interface AnnotationName) were being
handled as ObjC interfaces. This caused the brace formatting to mess up, so
that when you had a class with an interface defined in it, it would indent the
final brace of the class.
It used to format this class like so:
class A {
@interface B {}
}
But will now just skip the @interface and format it like so:
class A {
@interface B {}
}
Patch by Sam Maier!
Differential Revision: https://reviews.llvm.org/D53434
llvm-svn: 344789
This patch moves the virtual file system form clang to llvm so it can be
used by more projects.
Concretely the patch:
- Moves VirtualFileSystem.{h|cpp} from clang/Basic to llvm/Support.
- Moves the corresponding unit test from clang to llvm.
- Moves the vfs namespace from clang::vfs to llvm::vfs.
- Formats the lines affected by this change, mostly this is the result of
the added llvm namespace.
RFC on the mailing list:
http://lists.llvm.org/pipermail/llvm-dev/2018-October/126657.html
Differential revision: https://reviews.llvm.org/D52783
llvm-svn: 344140
The existing code kept the space if it was there for identifiers, and it didn't
handle `this`. After this patch, for Java `this` is handled in addition to
identifiers, and existing space is always stripped between identifier and `::`.
Also accept `::` in addition to `.` in front of `<` in `foo::<T>bar` generic
calls.
Differential Revision: https://reviews.llvm.org/D52842
llvm-svn: 343872
Summary:
Some macros are used in the body of function, and actually contain the trailing semicolon: they should thus be automatically followed by a new line, and not get merged with the next line. This is for example the case with Qt's Q_UNUSED macro:
void foo(int a, int b) {
Q_UNUSED(a)
return b;
}
This patch deals with these cases by introducing a new option to specify list of statement macros. This re-uses the system already in place for foreach macros, to ensure there is no impact on performance.
Reviewers: krasimir, djasper, klimek
Reviewed By: krasimir
Subscribers: acoomans, mgrang, alexfh, klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D33440
llvm-svn: 343602
Summary:
This change adds some rudimentary support for conditional types.
Specifically it avoids breaking before `extends` and `infer` keywords,
which are subject to Automatic Semicolon Insertion, so breaking before
them creates incorrect syntax.
The actual formatting of the type expression is odd, but there is as of
yet no clear idea on how to format these.
See https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-8.html#conditional-types.
Reviewers: krasimir
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D52536
llvm-svn: 343179
This fixes formatting namespaces with preceding 'inline' and 'export' (Modules TS) specifiers.
This change fixes namespaces not being identified as such with preceding 'inline' or 'export' specifiers.
Motivation: I was experimenting with the Modules TS (-fmodules-ts) and found it would be useful if clang-format would correctly format 'export namespace'. While making the changes, I noticed that similar issues still exist with 'inline namespace', and addressed them as well.
Patch by Marco Elver!
Reviewers: klimek, djasper, owenpan, sammccall
Reviewed By: owenpan, sammccall
Subscribers: owenpan, cfe-commits
Differential Revision: https://reviews.llvm.org/D51036
llvm-svn: 341450
Summary:
The Bug was reported and fixed by Owen Pan. See the original bug report here: https://bugs.llvm.org/show_bug.cgi?id=38557
Patch by Owen Pan!
Reviewers: krasimir, djasper, klimek
Reviewed By: klimek
Subscribers: JonasToth, cfe-commits
Differential Revision: https://reviews.llvm.org/D50697
llvm-svn: 340624
Summary:
This fixes a bug in clang-format where the last line's penalty is not
taken into account when its ending is broken. Usually the last line's penalty
is handled by addNextStateToQueue, but in cases where the trailing `*/` is put
on a newline, the contents of the last line have to be considered for penalizing.
Reviewers: mprobst
Reviewed By: mprobst
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D50378
llvm-svn: 339123
Summary:
Previously, clang-format would avoid breaking before the first `{`
found, but then happily break before subsequent '{'s on the line. This
change fixes that by looking for the first location that has no opening
curly, if any.
This fixes the original commit by correcting the loop condition.
This reverts commit 66dc646e09b795b943668179c33d09da71a3b6bc.
Reviewers: krasimir
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D50249
llvm-svn: 338890
Krasimir Georgiev