------------------------------------------------------------------------
r324246 | mzeren-vmw | 2018-02-05 16:59:00 +0100 (Mon, 05 Feb 2018) | 33 lines

[clang-format] Re-land: Fixup #include guard indents after parseFile()

Summary:
When a preprocessor indent closes after the last line of normal code we do not
correctly fixup include guard indents. For example:

  #ifndef HEADER_H
  #define HEADER_H
  #if 1
  int i;
  #  define A 0
  #endif
  #endif

incorrectly reformats to:

  #ifndef HEADER_H
  #define HEADER_H
  #if 1
  int i;
  #    define A 0
  #  endif
  #endif

To resolve this issue we must fixup levels after parseFile(). Delaying
the fixup introduces a new state, so consolidate include guard search
state into an enum.

Reviewers: krasimir, klimek

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D42035
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_60@324331 91177308-0d34-0410-b5e6-96231b3b80d8

------------------------------------------------------------------------
r323904 | mzeren-vmw | 2018-01-31 21:05:50 +0100 (Wed, 31 Jan 2018) | 34 lines

[clang-format] Align preprocessor comments with #

Summary:
r312125, which introduced preprocessor indentation, shipped with a known
issue where "indentation of comments immediately before indented
preprocessor lines is toggled on each run". For example these two forms
toggle:

  #ifndef HEADER_H
  #define HEADER_H
  #if 1
  // comment
  #   define A 0
  #endif
  #endif

  #ifndef HEADER_H
  #define HEADER_H
  #if 1
     // comment
  #   define A 0
  #endif
  #endif

This happens because we check vertical alignment against the '#' yet
indent to the level of the 'define'. This patch resolves this issue by
aligning against the '#'.

Reviewers: krasimir, klimek, djasper

Reviewed By: krasimir

Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42408
------------------------------------------------------------------------


git-svn-id: https://llvm.org/svn/llvm-project/cfe/branches/release_60@324329 91177308-0d34-0410-b5e6-96231b3b80d8

This reverts commit 37e69667f748e1458b46483b7c1b8f9ba33eec44.

We're going to discuss its ramifications further before making a
conclusion.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@320747 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
If we write the following code, it goes over 100 columns, so we need to wrap it:

```
- (VeryLongReturnTypeName)veryLongMethodParameter:(VeryLongParameterName)thisIsAVeryLongParameterName
                              longMethodParameter:(LongParameterName)thisIsAlsoAnotherLongParameterName;
```

Currently, clang-format with the google style aligns the method parameter names on the first column:

```
- (VeryLongReturnTypeName)
veryLongMethodParameter:(VeryLongParameterName)thisIsAVeryLongParameterName
    longMethodParameter:(LongParameterName)thisIsAlsoAnotherLongParameterName;
```

We'd like clang-format in the google style to align these to column 4 for Objective-C:

```
- (VeryLongReturnTypeName)
    veryLongMethodParameter:(VeryLongParameterName)thisIsAVeryLongParameterName
            longMethodParameter:(LongParameterName)thisIsAlsoAnotherLongParameterName;
```

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

Reviewers: krasimir, djasper, klimek

Reviewed By: djasper

Subscribers: cfe-commits, thakis

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@320714 91177308-0d34-0410-b5e6-96231b3b80d8

Adding the new enumerator forced a bunch more changes into this patch than I
would have liked. The -Wtautological-compare warning was extended to properly
check the new comparison operator, clang-format needed updating because it uses
precedence levels as weights for determining where to break lines (and several
operators increased their precedence levels with this change), thread-safety
analysis needed changes to build its own IL properly for the new operator.

All "real" semantic checking for this operator has been deferred to a future
patch. For now, we use the relational comparison rules and arbitrarily give
the builtin form of the operator a return type of 'void'.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@320707 91177308-0d34-0410-b5e6-96231b3b80d8

This patch improves detection of ObjC header files.
Right now many ObjC headers, especially short ones, are categorized as C/C++.

Way of filtering still isn't the best, as most likely it should be token-based.

Contributed by jolesiak!

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@320479 91177308-0d34-0410-b5e6-96231b3b80d8

We currently use target_link_libraries without an explicit scope
specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables.
Dependencies added in this way apply to both the target and its
dependencies, i.e. they become part of the executable's link interface
and are transitive.

Transitive dependencies generally don't make sense for executables,
since you wouldn't normally be linking against an executable. This also
causes issues for generating install export files when using
LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM
library dependencies, which are currently added as interface
dependencies. If clang is in the distribution components but the LLVM
libraries it depends on aren't (which is a perfectly legitimate use case
if the LLVM libraries are being built static and there are therefore no
run-time dependencies on them), CMake will complain about the LLVM
libraries not being in export set when attempting to generate the
install export file for clang. This is reasonable behavior on CMake's
part, and the right thing is for LLVM's build system to explicitly use
PRIVATE dependencies for executables.

Unfortunately, CMake doesn't allow you to mix and match the keyword and
non-keyword target_link_libraries signatures for a single target; i.e.,
if a single call to target_link_libraries for a particular target uses
one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must
also be updated to use those keywords. This means we must do this change
in a single shot. I also fully expect to have missed some instances; I
tested by enabling all the projects in the monorepo (except dragonegg),
and configuring both with and without shared libraries, on both Darwin
and Linux, but I'm planning to rely on the buildbots for other
configurations (since it should be pretty easy to fix those).

Even after this change, we still have a lot of target_link_libraries
calls that don't specify a scope keyword, mostly for shared libraries.
I'm thinking about addressing those in a follow-up, but that's a
separate change IMO.

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



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@319840 91177308-0d34-0410-b5e6-96231b3b80d8

Before, we would not break:
  int a = foo(/* trailing */);
when the end of /* trailing */ was exactly the column limit; the reason
is that block comments can have an unbreakable tail length - in this case
2, for the trailing ");"; we would unconditionally account that when
calculating the column state at the end of the token, but not correctly
add it into the remaining column length before, as we do for string
literals.
The fix is to correctly account the trailing unbreakable sequence length
into our formatting decisions for block comments. Line comments cannot
have a trailing unbreakable sequence, so no change is needed for them.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@319642 91177308-0d34-0410-b5e6-96231b3b80d8

When we break a long line like:
Column limit: 21
                      |
  // foo foo foo foo foo foo foo foo foo foo foo foo

The local decision when to allow protruding vs. breaking can lead to this
outcome (2 excess characters, 2 breaks):
  // foo foo foo foo foo
  // foo foo foo foo foo
  // foo foo

While strictly staying within the column limit leads to this strictly better
outcome (fully below the column limit, 2 breaks):
  // foo foo foo foo
  // foo foo foo foo
  // foo foo foo foo

To get an optimal solution, we would need to consider all combinations of excess
characters vs. breaking for all lines, but that would lead to a significant
increase in the search space of the algorithm for little gain.

Instead, we blindly try both approches and·select the one that leads to the
overall lower penalty.

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@319541 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
Otherwise automatic semicolon insertion can trigger, i.e. wrapping
produces invalid syntax.

Reviewers: djasper

Subscribers: klimek, cfe-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@319415 91177308-0d34-0410-b5e6-96231b3b80d8

This fixes some bugs in the reflowing logic and splits out the concerns
of reflowing from BreakableToken.

Things to do after this patch:
- Refactor the breakProtrudingToken function possibly into a class, so we
  can split it up into methods that operate on the common state.
- Optimize whitespace compression when reflowing by using the next possible
  split point instead of the latest possible split point.
- Retry different strategies for reflowing (strictly staying below the
  column limit vs. allowing excess characters if possible).

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@319314 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
This patch allows grouping multiple #include blocks together and sort all includes as one big block.
Additionally, sorted includes can be regrouped after sorting based on configured categories.

Contributed by @KrzysztofKapusta!

Reviewers: krasimir

Reviewed By: krasimir

Subscribers: cfe-commits, klimek

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@319024 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
clang-format does not collapse short records, interfaces, unions, etc.,
but fails to do so if the record is preceded by certain modifiers
(export, default, abstract, declare). This change skips over all
modifiers, and thus handles all record definitions uniformly.

Before:
    export class Foo { bar: string; }
    class Baz {
      bam: string;
    }

After:
    export class Foo {
      bar: string;
    }
    class Baz {
      bam: string;
    }

Reviewers: djasper

Subscribers: klimek

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318976 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
TypeScript generic type arguments can contain object (literal) types,
which in turn can contain semicolons:

    const x: Array<{a: number; b: string;} = [];

Previously, clang-format would incorrectly categorize the braced list as
a block and terminate the line at the openening `{`, and then format the
entire expression badly.

With this change, clang-format recognizes `<` preceding a `{` as
introducing a type expression. In JS, `<` comparison with an object
literal can never be true, so the chance of introducing false positives
here is very low.

Reviewers: djasper

Subscribers: klimek, cfe-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318975 91177308-0d34-0410-b5e6-96231b3b80d8

Summary: Previously, clang-format would fail formatting `{for: 1}`.

Reviewers: djasper

Subscribers: klimek

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318974 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
Automatic Semicolon Insertion in clang-format tries to guess if a line
wrap should insert an implicit semicolong. The previous heuristic would
not trigger ASI if a token was immediately preceded by an `@` sign:

    function foo(@Bar  // <-- does not trigger due to preceding @
                baz) {}

However decorators can have arbitrary parameters:

    function foo(@Bar(param, param, param)  // <-- precending @ missed
                baz) {}

While it would be possible to precisely find the matching `@`, just
conversatively disabling ASI for the entire line is simpler, while also
not regressing ASI substatially.

Reviewers: djasper

Subscribers: klimek, cfe-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318973 91177308-0d34-0410-b5e6-96231b3b80d8

Summary: This deduplicated equivalent using declarations within a block.

Reviewers: bkramer

Reviewed By: bkramer

Subscribers: cfe-commits, klimek

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318960 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
Wrapping between the type name and the array type indicator creates
invalid syntax in TypeScript.

Before:
    const xIsALongIdent:
        YJustBarelyFitsLinex
            [];  // illegal syntax.

After:
    const xIsALongIdent:
        YJustBarelyFitsLinex[];

Reviewers: djasper

Subscribers: klimek

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318959 91177308-0d34-0410-b5e6-96231b3b80d8

Summary: The same rules apply as for `return`.

Reviewers: djasper

Subscribers: klimek

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318958 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
Before:
    x = y!in z;
After:
    x = y! in z;

Reviewers: djasper

Subscribers: klimek

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318957 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
Previously, clang-format would drop a space character between `of` and
then following (non-identifier) token if the preceding token was part of
a destructuring assignment (`}` or `]`).

Before:
    for (const [a, b] of[]) {}

After:
    for (const [a, b] of []) {}

Reviewers: djasper

Subscribers: klimek

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318942 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
clang-format already removes empty lines at the beginning & end of
blocks:

    int x() {

      foo();  // lines before and after will be removed.

    }

However because lamdas and arrow functions are parsed as expressions,
the existing logic to remove empty lines in UnwrappedLineFormatter
doesn't handle them.

This change special cases arrow functions in ContinuationIndenter to
remove empty lines:

    x = []() {

      foo();  // lines before and after will now be removed.

    };

Reviewers: djasper

Subscribers: klimek, cfe-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318537 91177308-0d34-0410-b5e6-96231b3b80d8

For each line that we break in a protruding token, compute whether the
penalty of breaking is actually larger than the penalty of the excess
characters. Only break if that is the case.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318515 91177308-0d34-0410-b5e6-96231b3b80d8

Create more orthogonal pieces. The restructuring made it easy to try out
several alternatives to D33589, and while none of the alternatives
turned out to be the right solution, the underlying simplification of
the structure is helpful.

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318141 91177308-0d34-0410-b5e6-96231b3b80d8

This fixes clang-format internal assertion for the following code:

  /* override */ using std::string;

Patch by Igor Sugak. Thank you.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@317901 91177308-0d34-0410-b5e6-96231b3b80d8

Summary: This patch adds support for python-style comments in text protos.

Reviewers: djasper

Reviewed By: djasper

Subscribers: bkramer, cfe-commits, klimek

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@317886 91177308-0d34-0410-b5e6-96231b3b80d8

Summary: This patch improves using declarations sorting.

Reviewers: bkramer

Reviewed By: bkramer

Subscribers: cfe-commits, klimek

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@317794 91177308-0d34-0410-b5e6-96231b3b80d8

Before:
  int operator++(int)noexcept;

After:
  int operator++(int) noexcept;

Patch by Igor Sugak. Thank you!

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@317473 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
This makes clang-format sort using declarations case-sensitive with the
exception that '_' comes just before 'A'. This is better than the current case
insensitive version, because it groups uppercase names in the same namespace
together.

Reviewers: bkramer

Reviewed By: bkramer

Subscribers: cfe-commits, klimek

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@317325 91177308-0d34-0410-b5e6-96231b3b80d8

Subscribers: klimek

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

Contributed by @peterbudai!

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316910 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
This patch adds raw string literal formatting.

Reviewers: djasper, klimek

Reviewed By: klimek

Subscribers: klimek, mgorny

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316903 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
This patch enables sorting the full block of using declarations when
some line is affected.

Reviewers: djasper

Reviewed By: djasper

Subscribers: cfe-commits, klimek

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@316130 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
This patch enables `BreakableToken` to manage the formatting of non-trailing
block comments. It is a refinement of https://reviews.llvm.org/D37007.
We discovered that the optimizer outsmarts us on cases where breaking the comment
costs considerably less than breaking after the comment. This patch addresses
this by ensuring that a newline is inserted between a block comment and the next
token.

Reviewers: djasper

Reviewed By: djasper

Subscribers: cfe-commits, klimek

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@315893 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
This patch fixes a regression introduced in r312904, where the formatter confuses
the `else` in `#else` with an `else` of an `if-else` statement.
For example, formatting this code with google style
```
#ifdef A
int f() {}
#else
int f() {}
#endif
```
resulted in
```
#ifdef A
int f() {}
#else
int f() {
}
#endif
```

Reviewers: sammccall

Reviewed By: sammccall

Subscribers: klimek, cfe-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314683 91177308-0d34-0410-b5e6-96231b3b80d8

https://reviews.llvm.org/rL299952 merged '>>>' tokens into a single
JavaRightLogicalShift token. This broke formatting of generics nested more than
two deep, e.g. Foo<Bar<Baz>>> because the '>>>' now weren't three '>' for
parseAngle().

Luckily, just deleting JavaRightLogicalShift fixes things without breaking the
test added in r299952, so do that.

https://reviews.llvm.org/D38291


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314325 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
NamespaceEndCommentsFixer did not fix namespace comments when the brace opening the namespace was not on the same line as the "namespace" keyword.
It occurs in Allman, GNU and Linux styles and whenever BraceWrapping.AfterNamespace is true.

Before:
```lang=cpp
    namespace a
    {
    void f();
    void g();
    }
```

After:
```lang=cpp
    namespace a
    {
    void f();
    void g();
    } // namespace a
```

Reviewers: krasimir

Reviewed By: krasimir

Subscribers: klimek, cfe-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314279 91177308-0d34-0410-b5e6-96231b3b80d8

Keep space before or after the &/&& tokens, but not both. For example,
  auto [x,y] = a;
  auto &[xr, yr] = a; // LLVM style
  auto& [xr, yr] = a; // google style

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



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314264 91177308-0d34-0410-b5e6-96231b3b80d8

Previously, it was missing if the expression after the assert started with a (.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@314172 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
This ignores case while sorting using-declarations, fixing a case where `_` would appear between lowercase and uppercase characters.
It also applies stable sort, so that replacements for the exact same using declarations are not generated.

Reviewers: klimek, alexfh

Reviewed By: alexfh

Subscribers: cfe-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@313963 91177308-0d34-0410-b5e6-96231b3b80d8

Correctly determine when [ is part of a structured binding instead of a
lambda.

To be able to reuse the implementation already available, this patch also:
- sets the Previous link of FormatTokens in the UnwrappedLineParser
- moves the isCppStructuredBinding function into FormatToken

Before:
  auto const const &&[x, y] { A *i };

After:
  auto const const && [x, y]{A * i};

Fixing formatting of the type of the structured binding is still missing.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@313742 91177308-0d34-0410-b5e6-96231b3b80d8