If clang-format is confronted with long and deeply nested lines (e.g.
complex static initializers or function calls), it can currently try too
hard to find the optimal solution and never finish. The reason is that
the memoization does not work effectively for deeply nested lines.

This patch removes an earlier workaround and instead opts for
accepting a non-optimal solution in rare cases. However, it only does
so only in cases where it would have to analyze an excessive number of
states (currently set to 10000 - the most complex line in Format.cpp
requires ~800 states) so this should not change the behavior in a
relevant way.

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

The crash is triggered by the newly added option (-analyzer-config report-in-main-source-file=true) introduced in r182058.

Note, ideally, we’d like to report the issue within the main source file here as well.
For now, just do not crash.

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

operand of a unary address-of expression, not for *all* expressions!


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

function templates can use it as a return type.


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

*that* easy...

Try a bit harder to disambiguate. This is mostly straightforward, but for
=-style initializers, we actually need to know where an expression ends:

  [foo = bar baz]

is a message send, whereas

  [foo = bar + baz]

is a lambda-introducer. Handle this by parsing the expression eagerly, and
replacing it with an annotation token. By chance, we use the *exact same*
parsing rules in both cases (except that we need to assume we're inside a
message send for the parse, to turn off various forms of inapplicable
error recovery).


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

[analyzer;alternate edges] prune out extra edges to a subexpression where we dive-in and out of a subexpression.

Fixes <rdar://problem/13941891>.

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

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

variables when they are used in such unevaluated 
contexts as __typeof, etc. // rdar://13942025


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

common function. The C++1y contextual implicit conversion rules themselves are
not yet implemented, however.

This also fixes a subtle bug where template instantiation context notes were
dropped for diagnostics coming from conversions for integral constant
expressions -- we were implicitly slicing a SemaDiagnosticBuilder into a
DiagnosticBuilder when producing these diagnostics, and losing their context
notes in the process.


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

Debug Info: Simplify the code changed in r182403 to reduce indent & avoid a duplicate lookup in the insertion case

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

(no intended behavior change)

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

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

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

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

With this patch, clang-format will try to keep the cursor at the
original code position in editor integrations (implemented for emacs and
vim). This means, after formatting, clang-format will try to keep the
cursor on the same character of the same token.

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

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

Before:
void someLongFunction(
    int someLongParameter) const;

After:
void someLongFunction(int someLongParameter)
    const;

Also slightly cleanup tests.

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

attach, rather than merging all comments on the declaration chain. This gives a
more faithful dump, and has the side benefit of unbreaking uses of dump() from
within AST deserialization (where the redeclaration chain may not be sane).


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

Fixes <rdar://problem/13942300>.

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

@class command on an @interface declaration. Turn off
the warning for this case. // rdar://13927330


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

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

nonexistent Darwin-specific files on every module build.


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

This resolves the last of the PR14606 failures in the GDB 7.5 test
suite. (but there are still unresolved issues in the imported_decl case
- we need to implement optional/lazy decls for functions & variables
like we already do for types)

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

AsmPrinter::EmitLinkage() does not handle dllimport linkage.  The LLVM
verifier should also be fixed to reject this.

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

protocols that declare the same property of incompatible
types, issue a warning when class implementation synthesizes 
the property. // rdar://13075400


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

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

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

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

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

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

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

While the C++ standard requires that this lookup take place only at the
definition point of a virtual destructor (C++11 [class.dtor]p12), the
Microsoft ABI may require the compiler to emit a deleting destructor
for any virtual destructor declared in the TU, including ones without
a body, requiring an operator delete() lookup for every virtual
destructor declaration.  The result of the lookup should be the same
no matter which declaration is used (except in weird corner cases).

This change will cause us to reject some valid TUs in Microsoft ABI
mode, e.g.:

struct A {
  void operator delete(void *);
};

struct B {
  void operator delete(void *);
};

struct C : A, B {
  virtual ~C();
};

As Richard points out, every virtual function declared in a TU
(including this virtual destructor) is odr-used, so it must be defined
in any program which declares it, or the program is ill formed, no
diagnostic required.  Because we know that any definition of this
destructor will cause the lookup to fail, the compiler can choose to
issue a diagnostic here.

Differential Revision: http://llvm-reviews.chandlerc.com/D822

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

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

Fixes <rdar://problem/13933913>.


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

selectany only applies to externally visible global variables.  It has
the effect of making the data weak_odr.

The MSDN docs suggest that unused definitions can only be dropped at
linktime, so Clang uses weak instead of linkonce.  MSVC optimizes away
references to constant selectany data, so it must assume that there is
only one definition, hence weak_odr.

Reviewers: espindola

Differential Revision: http://llvm-reviews.chandlerc.com/D814

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

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

Add -Wincomplete-module, which detects when a header is included from a module but isn't itself part of a module.


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

Revert "Revert "Debug Info: Using declarations/DW_TAG_imported_declaration of variables, types, and functions.""

This reverts commit r181947 (git d2990ce56a16050cac0d7937ec9919ff54c6df62 )

This addresses one of the two issues identified in r181947, ensuring
that types imported via using declarations only result in a declaration
being emitted for the type, not a definition. The second issue (emitting
using declarations that are unused) is hopefully an acceptable increase
as the real fix for this would be a bit difficult (probably at best we
could record which using directives were involved in lookups - but may
not have been the result of the lookup).

This also ensures that DW_TAG_imported_declarations (& directives) are
not emitted in line-tables-only mode as well as ensuring that typedefs
only require/emit declarations (rather than definitions) for referenced
types.

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

Other operating systems, including FreeBSD and NetBSD, use long.

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

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