clang-format: distinguish ObjC call subexpressions after r355434

Summary:
The revision r355434 had the unfortunate side-effect that it started to
recognize certain ObjC expressions with a call subex

clang-format: distinguish ObjC call subexpressions after r355434

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

show more ...

[Format/ObjC] Fix [foo bar]->baz formatting as lambda arrow

Summary:
Currently, `UnwrappedLineParser` thinks an arrow token after
an ObjC method expression is a C++ lambda arrow, so it formats:

```

[Format/ObjC] Fix [foo bar]->baz formatting as lambda arrow

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

show more ...

[clang-format] square parens with one token are not Objective-C message sends

The commit r322690 introduced support for ObjC detection in header files.
Unfortunately some C headers that use designat

[clang-format] square parens with one token are not Objective-C message sends

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

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
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

show more ...

[clang-format] Fix BraceWrapping AfterFunction for ObjC methods

Summary:
> clang-format --version
> clang-format version 7.0.0 (tags/RELEASE_700/final)
> echo "@implementation Foo\n- (void)foo:(id)b

[clang-format] Fix BraceWrapping AfterFunction for ObjC methods

Summary:
> clang-format --version
> clang-format version 7.0.0 (tags/RELEASE_700/final)
> echo "@implementation Foo\n- (void)foo:(id)bar\n{\n}\n@end\n" |clang-format -style='{BreakBeforeBraces: Custom, BraceWrapping: {AfterFunction: true}}'
```
@implementation Foo
- (void)foo:(id)bar {
}
@end
```

with patch:

> bin/clang-format --version
> clang-format version 8.0.0 (trunk 344285)
> echo "@implementation Foo\n- (void)foo:(id)bar\n{\n}\n@end\n" |bin/clang-format -style='{BreakBeforeBraces: Custom, BraceWrapping: {AfterFunction: true}}'
```
@implementation Foo
- (void)foo:(id)bar
{
}
@end
```

Contributed by hultman@.

Reviewers: benhamilton, jolesiak, klimek, Wizard

Reviewed By: benhamilton

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D53197

llvm-svn: 344406

show more ...

[clang-format/ObjC] Put ObjC method arguments into one line when they fit

Reapply D47195:
Currently BreakBeforeParameter is set to true everytime message receiver spans multiple lines, e.g.:
```
[[o

[clang-format/ObjC] Put ObjC method arguments into one line when they fit

Reapply D47195:
Currently BreakBeforeParameter is set to true everytime message receiver spans multiple lines, e.g.:
```
[[object block:^{
return 42;
}] aa:42 bb:42];
```
will be formatted:
```
[[object block:^{
return 42;
}] aa:42
bb:42];
```
even though arguments could fit into one line. This change fixes this behavior.

llvm-svn: 336521

show more ...

[clang-format/ObjC] Improve split priorities for ObjC methods

Reduce penalty for aligning ObjC method arguments using the colon alignment as
this is the canonical way.

Trying to fit a whole express

[clang-format/ObjC] Improve split priorities for ObjC methods

Reduce penalty for aligning ObjC method arguments using the colon alignment as
this is the canonical way.

Trying to fit a whole expression into one line should not force other line
breaks (e.g. when ObjC method expression is a part of other expression).

llvm-svn: 336520

show more ...

[clang-format/ObjC] Fix NS_SWIFT_NAME(foo(bar:baz:)) after ObjC method decl

Summary:
In D44638, I partially fixed `NS_SWIFT_NAME(foo(bar:baz:))`-style
annotations on C functions, but didn't add a te

[clang-format/ObjC] Fix NS_SWIFT_NAME(foo(bar:baz:)) after ObjC method decl

Summary:
In D44638, I partially fixed `NS_SWIFT_NAME(foo(bar:baz:))`-style
annotations on C functions, but didn't add a test for Objective-C
method declarations.

For ObjC method declarations which are annotated with `NS_SWIFT_NAME(...)`,
we currently fail to annotate the final component of the selector
name as `TT_SelectorName`.

Because the token type is left unknown, clang-format will happily
cause a compilation error when it changes the following:

```
@interface Foo
- (void)doStuffWithFoo:(id)name
bar:(id)bar
baz:(id)baz
NS_SWIFT_NAME(doStuff(withFoo:bar:baz:));
@end
```

to:

```
@interface Foo
- (void)doStuffWithFoo:(id)name
bar:(id)bar
baz:(id)baz
NS_SWIFT_NAME(doStuff(withFoo:bar:baz
:));
@end
```

(note the linebreak before the final `:`).

The logic which decides whether or not to annotate the token before a
`:` with `TT_SelectorName` is pretty fragile, and has to handle some
pretty odd cases like pair-parameters:

```
[I drawRectOn:surface ofSize:aa:bbb atOrigin:cc:dd];
```

So, to minimize the effect of this change, I decided to only annotate
unknown identifiers before a `:` as `TT_SelectorName` for Objective-C
declaration lines.

Test Plan: New tests included. Confirmed tests failed before change and
passed after change. Ran tests with:
% make -j16 FormatTests && ./tools/clang/unittests/Format/FormatTests

Reviewers: djasper, krasimir, jolesiak

Reviewed By: krasimir

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D48679

llvm-svn: 335983

show more ...

[clang-format] Add AlwaysBreakBeforeMultilineString tests

Summary: Followup to D47393.

Reviewers: stephanemoore

Reviewed By: stephanemoore

Subscribers: benhamilton, cfe-commits

Differential Revi

[clang-format] Add AlwaysBreakBeforeMultilineString tests

Summary: Followup to D47393.

Reviewers: stephanemoore

Reviewed By: stephanemoore

Subscribers: benhamilton, cfe-commits

Differential Revision: https://reviews.llvm.org/D48432

llvm-svn: 335338

show more ...

[clang-format] Disable AlwaysBreakBeforeMultilineStrings in Google style for Objective-C ��

Contributed by @stephanemoore.

Reviewers: benhamilton, jolesiak, djasper

Reviewed By: benhamilton

Subsc

[clang-format] Disable AlwaysBreakBeforeMultilineStrings in Google style for Objective-C ��

Contributed by @stephanemoore.

Reviewers: benhamilton, jolesiak, djasper

Reviewed By: benhamilton

Subscribers: klimek, cfe-commits

Differential Revision: https://reviews.llvm.org/D47393

llvm-svn: 334739

show more ...

[clang-format/ObjC] Correctly parse Objective-C methods with 'class' in name

Summary:
Please take a close look at this CL. I haven't touched much of
`UnwrappedLineParser` before, so I may have gotte

[clang-format/ObjC] Correctly parse Objective-C methods with 'class' in name

Summary:
Please take a close look at this CL. I haven't touched much of
`UnwrappedLineParser` before, so I may have gotten things wrong.

Previously, clang-format would incorrectly format the following:

```
@implementation Foo

- (Class)class {
}

- (void)foo {
}

@end
```

as:

```
@implementation Foo

- (Class)class {
}

- (void)foo {
}

@end
```

The problem is whenever `UnwrappedLineParser::parseStructuralElement()`
sees any of the keywords `class`, `struct`, or `enum`, it calls
`parseRecord()` to parse them as a C/C++ record.

This causes subsequent lines to be parsed incorrectly, which
causes them to be indented incorrectly.

In Objective-C/Objective-C++, these keywords are valid selector
components.

This diff fixes the issue by explicitly handling `+` and `-` lines
inside `@implementation` / `@interface` / `@protocol` blocks
and parsing them as Objective-C methods.

Test Plan: New tests added. Ran tests with:
make -j16 FormatTests && ./tools/clang/unittests/Format/FormatTests

Reviewers: jolesiak, klimek

Reviewed By: jolesiak, klimek

Subscribers: klimek, cfe-commits, Wizard

Differential Revision: https://reviews.llvm.org/D47095

llvm-svn: 333553

show more ...

Revert "[clang-format] Fix putting ObjC message arguments in one line for multiline receiver"

Summary:
This reverts commit db9e5e9a616d7fdd4d1ba4c3b2cd89d8a0238533 (rC333171).

Mentioned change intr

Revert "[clang-format] Fix putting ObjC message arguments in one line for multiline receiver"

Summary:
This reverts commit db9e5e9a616d7fdd4d1ba4c3b2cd89d8a0238533 (rC333171).

Mentioned change introduced unintended formatting of ObjC code due to split priorities inherited from C/C++, e.g.:
```
fooooooo = [
[obj fooo] aaa:42 aaa:42];
```
instead of
```
fooooooo =
[[obj fooo] aaa:42
aaa:42];
```
when formatted with ColumnLimit = 30.

Reviewers: krasimir

Reviewed By: krasimir

Subscribers: benhamilton, klimek, cfe-commits

Differential Revision: https://reviews.llvm.org/D47527

llvm-svn: 333539

show more ...

[clang-format] Fix putting ObjC message arguments in one line for multiline receiver

Summary:
Reapply reverted changes from D46879.

Currently BreakBeforeParameter is set to true everytime message r

[clang-format] Fix putting ObjC message arguments in one line for multiline receiver

Summary:
Reapply reverted changes from D46879.

Currently BreakBeforeParameter is set to true everytime message receiver spans multiple lines, e.g.:
```
[[object block:^{
return 42;
}] aa:42 bb:42];
```
will be formatted:
```
[[object block:^{
return 42;
}] aa:42
bb:42];
```
even though arguments could fit into one line. This change fixes this behavior.

Test Plan:
make -j12 FormatTests && tools/clang/unittests/Format/FormatTests

Reviewers: benhamilton, krasimir

Reviewed By: benhamilton, krasimir

Subscribers: djasper, klimek, cfe-commits

Differential Revision: https://reviews.llvm.org/D47195

llvm-svn: 333171

show more ...

Revert "[clang-format] Fix putting ObjC message arguments in one line for multiline receiver"

Summary: Reverts D46879

Reviewers: benhamilton

Reviewed By: benhamilton

Subscribers: krasimir, klimek

Revert "[clang-format] Fix putting ObjC message arguments in one line for multiline receiver"

Summary: Reverts D46879

Reviewers: benhamilton

Reviewed By: benhamilton

Subscribers: krasimir, klimek, cfe-commits

Differential Revision: https://reviews.llvm.org/D47205

llvm-svn: 332998

show more ...

[clang-format/ObjC] Correctly annotate single-component ObjC method invocations

Summary:
Previously, clang-format's parser would fail to annotate the
selector in a single-component Objective-C metho

[clang-format/ObjC] Correctly annotate single-component ObjC method invocations

Summary:
Previously, clang-format's parser would fail to annotate the
selector in a single-component Objective-C method invocation with
`TT_SelectorName`. For example, the following:

[foo bar];

would parse `bar` as `TT_Unknown`:

M=0 C=1 T=Unknown S=0 B=0 BK=0 P=140 Name=identifier L=34 PPK=2
FakeLParens= FakeRParens=0 II=0x559d5db51770 Text='bar'

This caused us to fail to insert a space after a closing cast rparen,
so the following:

[((Foo *)foo) bar];

would format as:

[((Foo *)foo)bar];

This diff fixes the issue by ensuring we annotate the selector
in a single-component Objective-C method invocation as
`TT_SelectorName`.

Test Plan: New tests added. Ran tests with:
% make -j16 FormatTests && ./tools/clang/unittests/Format/FormatTests

Reviewers: djasper, jolesiak

Reviewed By: jolesiak

Subscribers: Wizard, klimek, hokein, cfe-commits

Differential Revision: https://reviews.llvm.org/D47028

llvm-svn: 332727

show more ...

[clang-format] Fix putting ObjC message arguments in one line for multiline receiver

Summary:
Currently BreakBeforeParameter is set to true everytime message receiver spans multiple lines, e.g.:
```

[clang-format] Fix putting ObjC message arguments in one line for multiline receiver

Summary:
Currently BreakBeforeParameter is set to true everytime message receiver spans multiple lines, e.g.:
```
[[object block:^{
return 42;
}] aa:42 bb:42];
```
will be formatted:
```
[[object block:^{
return 42;
}] aa:42
bb:42];
```
even though arguments could fit into one line. This change fixes this behavior.

Test Plan:
make -j12 FormatTests && tools/clang/unittests/Format/FormatTests

Reviewers: benhamilton, djasper

Reviewed By: benhamilton

Subscribers: klimek, cfe-commits

Differential Revision: https://reviews.llvm.org/D46879

llvm-svn: 332582

show more ...

[clang] Update uses of DEBUG macro to LLVM_DEBUG.

The DEBUG() macro is very generic so it might clash with other projects.
The renaming was done as follows:
- git grep -l 'DEBUG' | xargs sed -i 's/\

[clang] Update uses of DEBUG macro to LLVM_DEBUG.

The DEBUG() macro is very generic so it might clash with other projects.
The renaming was done as follows:
- git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g'
- git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM

Explicitly avoided changing the strings in the clang-format tests.

Differential Revision: https://reviews.llvm.org/D44975

llvm-svn: 332350

show more ...

[clang-format] Continue after non-scope-closers in getLengthToMatchingParen

Summary:
This fixes a regression introduced by `r331857` where we stop the search for
the End token as soon as we hit a no

[clang-format] Continue after non-scope-closers in getLengthToMatchingParen

Summary:
This fixes a regression introduced by `r331857` where we stop the search for
the End token as soon as we hit a non-scope-closer, which prematurely stops before
semicolons for example, which should otherwise be considered as part of the unbreakable tail.

Subscribers: klimek, cfe-commits

Differential Revision: https://reviews.llvm.org/D46824

llvm-svn: 332225

show more ...

[clang-format/ObjC] Use getIdentifierInfo() instead of tok::identifier

Summary:
Previously, we checked tokens for `tok::identifier` to see if they
were identifiers inside an Objective-C selector.

H

[clang-format/ObjC] Use getIdentifierInfo() instead of tok::identifier

Summary:
Previously, we checked tokens for `tok::identifier` to see if they
were identifiers inside an Objective-C selector.

However, this missed C++ keywords like `new` and `delete`.

To fix this, this diff uses `getIdentifierInfo()` to find
identifiers or keywords inside Objective-C selectors.

Test Plan: New tests added. Ran tests with:
% make -j16 FormatTests && ./tools/clang/unittests/Format/FormatTests

Reviewers: djasper, jolesiak

Reviewed By: djasper

Subscribers: klimek, cfe-commits

Differential Revision: https://reviews.llvm.org/D46143

llvm-svn: 331067

show more ...

[clang-format] Do not break after ObjC category open paren

Summary:
Previously, `clang-format` would break Objective-C
category extensions after the opening parenthesis to avoid
breaking the protoco

[clang-format] Do not break after ObjC category open paren

Summary:
Previously, `clang-format` would break Objective-C
category extensions after the opening parenthesis to avoid
breaking the protocol list:

```
% echo "@interface ccccccccccccc (ccccccccccc) <ccccccccccccc> { }" | \
clang-format -assume-filename=foo.h -style="{BasedOnStyle: llvm, \
ColumnLimit: 40}"
@interface ccccccccccccc (
ccccccccccc) <ccccccccccccc> {
}
```

This looks fairly odd, as we could have kept the category extension
on the previous line.

Category extensions are a single item, so they are generally very
short compared to protocol lists. We should prefer breaking after the
opening `<` of the protocol list over breaking after the opening `(`
of the category extension.

With this diff, we now avoid breaking after the category extension's
open paren, which causes us to break after the protocol list's
open angle bracket:

```
% echo "@interface ccccccccccccc (ccccccccccc) <ccccccccccccc> { }" | \
./bin/clang-format -assume-filename=foo.h -style="{BasedOnStyle: llvm, \
ColumnLimit: 40}"
@interface ccccccccccccc (ccccccccccc) <
ccccccccccccc> {
}
```

Test Plan: New test added. Confirmed test failed before diff and
passed after diff by running:
% make -j16 FormatTests && ./tools/clang/unittests/Format/FormatTests

Reviewers: djasper, jolesiak

Reviewed By: djasper

Subscribers: klimek, cfe-commits

Differential Revision: https://reviews.llvm.org/D45526

llvm-svn: 329919

show more ...

[clang-format] Don't insert space between ObjC class and lightweight generic

Summary:
In D45185, I added clang-format parser support for Objective-C
generics. However, I didn't touch the whitespace

[clang-format] Don't insert space between ObjC class and lightweight generic

Summary:
In D45185, I added clang-format parser support for Objective-C
generics. However, I didn't touch the whitespace logic, so they
got the same space logic as Objective-C protocol lists.

In every example in the Apple SDK and in the documentation,
there is no space between the class name and the opening `<`
for the lightweight generic specification, so this diff
removes the space and updates the tests.

Test Plan: Tests updated. Ran tests with:
% make -j16 FormatTests && ./tools/clang/unittests/Format/FormatTests

Reviewers: djasper, jolesiak

Reviewed By: djasper

Subscribers: klimek, cfe-commits

Differential Revision: https://reviews.llvm.org/D45498

llvm-svn: 329917

show more ...

[clang-format] Always indent wrapped Objective-C selector names

Summary:
Currently, indentation of Objective-C method names which are wrapped
onto the next line due to a long return type is controll

[clang-format] Always indent wrapped Objective-C selector names

Summary:
Currently, indentation of Objective-C method names which are wrapped
onto the next line due to a long return type is controlled by the
style option `IndentWrappedFunctionNames`.

This diff changes the behavior so we always indent wrapped Objective-C
selector names.

NOTE: I partially reverted https://github.com/llvm-mirror/clang/commit/6159c0fbd1876c7f5f984b4830c664cc78f16e2e / rL242484, as it was causing wrapped selectors to be double-indented. Its tests in FormatTestObjC.cpp still pass.

Test Plan: Tests updated. Ran tests with:
% make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests

Reviewers: djasper, jolesiak, stephanemoore, thakis

Reviewed By: djasper

Subscribers: stephanemoore, klimek, cfe-commits

Differential Revision: https://reviews.llvm.org/D45004

llvm-svn: 329916

show more ...

[clang-format] Support lightweight Objective-C generics

Summary:
Previously, `clang-format` didn't understand lightweight
Objective-C generics, which have the form:

```
@interface Foo <KeyType,

[clang-format] Support lightweight Objective-C generics

Summary:
Previously, `clang-format` didn't understand lightweight
Objective-C generics, which have the form:

```
@interface Foo <KeyType,
ValueTypeWithConstraint : Foo,
AnotherValueTypeWithGenericConstraint: Bar<Baz>, ... > ...
```

The lightweight generic specifier list appears before the base
class, if present, but because it starts with < like the protocol
specifier list, `UnwrappedLineParser` was getting confused and
failed to parse interfaces with both generics and protocol lists:

```
@interface Foo <KeyType> : NSObject <NSCopying>
```

Since the parsed line would be incomplete, the format result
would be very confused (e.g., https://bugs.llvm.org/show_bug.cgi?id=24381).

This fixes the issue by explicitly parsing the ObjC lightweight
generic conformance list, so the line is fully parsed.

Fixes: https://bugs.llvm.org/show_bug.cgi?id=24381

Test Plan: New tests added. Ran tests with:
% make -j16 FormatTests && ./tools/clang/unittests/Format/FormatTests

Reviewers: djasper, jolesiak

Reviewed By: djasper

Subscribers: klimek, cfe-commits

Differential Revision: https://reviews.llvm.org/D45185

llvm-svn: 329298

show more ...

[clang-format] Ensure ObjC selectors with 0 args are annotated correctly

Summary:
Previously, clang-format would incorrectly annotate 0-argument
Objective-C selector names as TT_TrailingAnnotation:

[clang-format] Ensure ObjC selectors with 0 args are annotated correctly

Summary:
Previously, clang-format would incorrectly annotate 0-argument
Objective-C selector names as TT_TrailingAnnotation:

```
% echo "-(void)foo;" > /tmp/test.m
% ./bin/clang-format -debug /tmp/test.m
Language: Objective-C
----
Line(0, FSC=0): minus[T=68, OC=0] l_paren[T=68, OC=1] void[T=68, OC=2]
r_paren[T=68, OC=6] identifier[T=68, OC=7] semi[T=68, OC=10]
Line(0, FSC=0): eof[T=68, OC=0]
Run 0...
AnnotatedTokens(L=0):
M=0 C=0 T=ObjCMethodSpecifier S=1 B=0 BK=0 P=0 Name=minus L=1 PPK=2
FakeLParens= FakeRParens=0 Text='-'
M=0 C=1 T=Unknown S=1 B=0 BK=0 P=33 Name=l_paren L=3 PPK=2
FakeLParens= FakeRParens=0 Text='('
M=0 C=1 T=Unknown S=0 B=0 BK=0 P=140 Name=void L=7 PPK=2 FakeLParens=
FakeRParens=0 Text='void'
M=0 C=0 T=CastRParen S=0 B=0 BK=0 P=43 Name=r_paren L=8 PPK=2
FakeLParens= FakeRParens=0 Text=')'
M=0 C=1 T=TrailingAnnotation S=0 B=0 BK=0 P=120 Name=identifier L=11
PPK=2 FakeLParens= FakeRParens=0 Text='foo'
M=0 C=0 T=Unknown S=0 B=0 BK=0 P=23 Name=semi L=12 PPK=2 FakeLParens=
FakeRParens=0 Text=';'
```

This caused us to incorrectly indent 0-argument wrapped selectors
when Style.IndentWrappedFunctionNames was false, as we thought
the 0-argument ObjC selector name was actually a trailing
annotation (which is always indented).

This diff fixes the issue and adds tests.

Test Plan: New tests added. Confirmed tests failed before diff.
After diff, tests passed. Ran tests with:
% make -j12 FormatTests &&
./tools/clang/unittests/Format/FormatTests

Reviewers: djasper, jolesiak

Reviewed By: djasper, jolesiak

Subscribers: klimek, cfe-commits

Differential Revision: https://reviews.llvm.org/D44996

llvm-svn: 329297

show more ...

[clang-format] In tests, expected code should be format-stable

Summary: Extend various verifyFormat helper functions to check that the
expected text is "stable". This provides some protection agains

[clang-format] In tests, expected code should be format-stable

Summary: Extend various verifyFormat helper functions to check that the
expected text is "stable". This provides some protection against bugs
where formatting results are ocilating between two forms, or continually
change in some other way.

Testing Done:

* Ran unit tests.

* Reproduced a known instability in preprocessor indentation which was
caught by this new check.

Reviewers: krasimir

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D42034

llvm-svn: 329231

show more ...