------------------------------------------------------------------------
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

------------------------------------------------------------------------
r322390 | vsapsai | 2018-01-12 10:54:35 -0800 (Fri, 12 Jan 2018) | 20 lines

[Lex] Avoid out-of-bounds dereference in LexAngledStringLiteral.

Fix makes the loop in LexAngledStringLiteral more like the loops in
LexStringLiteral, LexCharConstant. When we skip a character after
backslash, we need to check if we reached the end of the file instead of
reading the next character unconditionally.

Discovered by OSS-Fuzz:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3832

rdar://problem/35572754

Reviewers: arphaman, kcc, rsmith, dexonsmith

Reviewed By: rsmith, dexonsmith

Subscribers: cfe-commits, rsmith, dexonsmith

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

------------------------------------------------------------------------


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

* Also introduces ImportTemplateArgumentListInfo facility (A. Sidorin)

This re-commits r320942 after fixing the behaviour on '-fdelayed-template-parsing'
option and adding additional checks.

Patch by Peter Szecsi!

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


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

Now tests for metadata created by clang involve compiling code snippets
placed into c/c++ source files and matching interesting patterns in the
obtained textual representation of IR. Writting such tests is a painful
process as metadata often form complex tree-like structures but textual
representation of IR contains only a pile of metadata at the module end.

This change implements IR matchers that may be used to match required
patterns in the binary IR representation. In this case the metadata
structure is not broken and creation of match patterns is easier.

The change adds unit tests for TBAA metadata generation.

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


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

An unscoped enumeration used as template argument, should not have any
qualified information about its enclosing scope, as its visibility is
global.

In the case of scoped enumerations, they must include information
about their enclosing scope.

Patch by Carlos Alberto Enciso!

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

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

 * While running ASTImporterTests, we often forget about Windows MSVC
   buildbots which enable '-fdelayed-template-parsing' by default.
   This leads to AST import errors because templates are not parsed
   and corresponding parts of AST are not built so importer cannot import them.
   It takes both reviewing time to find such issues and post-commit time
   to fix unexpected buildbot failures. To solve this issue, we enable testing
   with '-fdelayed-template-parsing' option enabled by default in addition
   to testing with default compiler options. This allows us to catch
   the problem during development.

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



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

Revert r320942, "[ASTImporter] Support importing FunctionTemplateDecl and CXXDependentScopeMemberExpr"

Caused a test failure on Windows:

[ RUN      ] ImportExpr.ImportCXXDependentScopeMemberExpr
C:\b\rr\tmppzcp4w\w\src\third_party\llvm\tools\clang\unittests\AST\ASTImporterTest.cpp(526): error: Value of: testImport("template <typename T> class C { T t; };" "template <typename T> void declToImport() {" "  C<T> d;" "  d.t;" "}", Lang_CXX, "", Lang_CXX, Verifier, functionTemplateDecl(has(functionDecl(has(compoundStmt( has(cxxDependentScopeMemberExpr())))))))
  Actual: false (Could not find match)
Expected: true
C:\b\rr\tmppzcp4w\w\src\third_party\llvm\tools\clang\unittests\AST\ASTImporterTest.cpp(534): error: Value of: testImport("template <typename T> class C { T t; };" "template <typename T> void declToImport() {" "  C<T> d;" "  (&d)->t;" "}", Lang_CXX, "", Lang_CXX, Verifier, functionTemplateDecl(has(functionDecl(has(compoundStmt( has(cxxDependentScopeMemberExpr())))))))
  Actual: false (Could not find match)
Expected: true
[  FAILED  ] ImportExpr.ImportCXXDependentScopeMemberExpr (37 ms)

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

* Also introduces ImportTemplateArgumentListInfo facility (A. Sidorin)

Patch by Peter Szecsi!

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


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@320942 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

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

As reported in llvm bugzilla 32377.
Here’s a patch to add preinclude of stdc-predef.h.

The gcc documentation says “On GNU/Linux, <stdc-predef.h> is pre-included.” See https://gcc.gnu.org/gcc-4.8/porting_to.html;

The preinclude is inhibited with –ffreestanding.

Basically I fixed the failing test cases by adding –ffreestanding which inhibits this behavior.

I fixed all the failing tests, including some in extra/test, there's a separate patch for that which is linked here

Note: this is a recommit after a test failure took down the original (r318669)

Patch By: mibintc
Differential Revision: https://reviews.llvm.org/D34158


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

Summary: This patch implements 4.3 of http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4220.pdf. If a raw string contains a newline character, replace each newline character with the \n escape code. Without this patch, included test case (macro_raw_string.cpp) results compilation failure.

Reviewers: rsmith, doug.gregor, jkorous-apple

Reviewed By: jkorous-apple

Subscribers: jkorous-apple, vsapsai, cfe-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@319904 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

Patch by Kareem Khazem!

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



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@319632 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

Patch by Julie Hockett.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@319360 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

Patch by Peter Szecsi!

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



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

Patch by Takafumi Kubota!

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



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@318998 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

Two new matchers for `CXXNewExpr` are added which may be useful e.g. in
`clang-tidy` checkers. One of them is `isArray` which matches `new[]` but not
plain `new`. The other one, `hasArraySize` matches `new[]` for a given size.



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

This saves some cycles when compiling with "-w".

(Also fix a potential crash on invalid code for tools that tries to recover from some
errors, because analysis might compute the CFG which crashes if the code contains
invalid declaration. This does not happen normally with because we also don't perform
these analysis if there was an error.)

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

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

When requesting a tooltip for a function call in an IDE, the fully
qualified name helps to remove ambiguity in the function signature.

Patch by Nikolai Kosjar!

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


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

Add an AST matcher for hasDefaultArgument() to match on parameter declarations that have a default value.

Patch by Julie Hockett.

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

Broke some libclang tests, so reverting for now.


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