isExternCTemplate() and getLanguageLinkageTemplate() have nothing to do with
templates despite the dubious naming scheme.

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

This allows us to be more careful when dealing with enums whose fixed
underlying type requires special handling in a format string, like
NSInteger.

A refinement of r163266 from a year and a half ago, which added the
special handling for NSInteger and friends in the first place.

<rdar://problem/16616623>

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

Also move the attribute-specific dumping to after dumping this and
the Implicit flag.

Differential Revision: http://reviews.llvm.org/D3971

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

This failure mode shows up occasionally when users try to include C headers in
C++ projects or when porting from Windows. We might as well recover in the way
the user expected, thus avoiding confusing diagnostic messages at point of use.

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

The checks below can hypothetically apply to converted operator name
identifiers.

In practice there are no builtin macros etc. with those names so there's no
behavioural change to test.

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

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

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

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

Differential Revision: http://reviews.llvm.org/D3973

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

I was bitten by this when working with the dll attributes: when a dll
attribute was cloned from a class template declaration to its
specialization, the Inherited flag didn't get cloned.

Differential Revision: http://reviews.llvm.org/D3972

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

There is no std::error_code::success, so this removes much of the noise
in transitioning to std::error_code.

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

[CodeGen] Don't cast and use SizeTy instead of Int32Ty when constructing {extract,insert} vector element instructions.

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

consistently, rather than sometimes performing lookup and calling the
LookupResult form. No functionality change intended.


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

This simplifies code flow and matches the convention used in surrounding code.

No functional change.

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

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

qualified name of a NamedDecl. Patch by Volodymyr Sapsai!


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

This reapplies r209910 with a fix for the assertion failures hit on the
buildbots.

original commit message:
I thought we could get away without this, but it means that the
FileEntry objects actually refer to the wrong files, since pcms are not
updated inplace, they are atomically renamed into place after compiling
a module.

So we are close to the original behaviour of invalidating the cache for
all modules being removed, but now we should only invalidate the ones
that depend on whichever module failed to load.

Unfortunately I haven't come up with a new test that didn't require
a race between parallel invocations of clang.

<rdar://problem/17038180>

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

This presumably got inadvertently copied from dllimport-members.cpp.

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

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

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

This reverts commit r209910, which is breaking some of the bots.

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

I thought we could get away without this, but it means that the
FileEntry objects actually refer to the wrong files, since pcms are not
updated inplace, they are atomically renamed into place after compiling
a module.

So we are close to the original behaviour of invalidating the cache for
all modules being removed, but now we should only invalidate the ones
that depend on whichever module failed to load.

Unfortunately I haven't come up with a new test that didn't require
a race between parallel invocations of clang.

<rdar://problem/17038180>

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

This implements the central part of support for dllimport/dllexport on
classes: allowing the attribute on class declarations, inheriting it
to class members, and forcing emission of exported members. It's based
on Nico Rieck's patch from http://reviews.llvm.org/D1099.

This patch doesn't propagate dllexport to bases that are template
specializations, which is an interesting problem. It also doesn't
look at the rules when redeclaring classes with different attributes,
I'd like to do that separately.

Differential Revision: http://reviews.llvm.org/D3877

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

an Objective-C object type other than 'id'. 
// rdar://16739120


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

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

There shouldn't be any difference in behaviour here, at least not in
any configurations people care about and possibly not in any reachable
configurations.

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

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

This test is no longer relevant. It is covered already by [basic.scope.pdecl]p10, and our current test for that is more thorough (though our test is named p9.cpp).

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

This test should no longer be XFAILed; the standard has stabilized, and the test contents are acceptable. No diagnostics expected from this test.

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

Setting a heading for the section/allocate attribute so that the attribute documentation can be properly generated.

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

You could see unexpected result (*.tmp.err) with "-target x86_64-win32".

  Weverything-and-remarks.cpp:11:9: warning: 'char32_t' type specifier is incompatible with C++98 [-Wc++98-compat]
  typedef __char32_t char32_t;
          ^
  Weverything-and-remarks.cpp:12:27: error: typedef redefinition with different types ('unsigned long' vs 'unsigned long long')
  typedef long unsigned int size_t;
                            ^
  Weverything-and-remarks.cpp:19:62: warning: dynamic exception specifications are deprecated [-Wdeprecated]
    static void assign(char_type& __c1, const char_type& __c2) throw() {
                                                               ^~~~~~~
  Weverything-and-remarks.cpp:19:62: note: use 'noexcept' instead
    static void assign(char_type& __c1, const char_type& __c2) throw() {
                                                               ^~~~~~~
                                                               noexcept
  Weverything-and-remarks.cpp:25:46: warning: unused parameter '__n' [-Wunused-parameter]
                                        size_t __n) {
                                               ^
  3 warnings and 1 error generated.

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

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

http://llvm.org/bugs/show_bug.cgi?id=19876

The following C++1y code results in a crash:

struct X {
  int m = 10;
  int n = [this](auto) { return m; }(20);
};

When implicitly instantiating the generic lambda's call operator specialization body, Sema is unable to determine the current 'this' type when transforming the MemberExpr 'm' - since it looks for the nearest enclosing FunctionDeclDC - which is obviously null.

I considered two ways to fix this:

    1) In InstantiateFunctionDefinition, when the context is saved after the lambda scope info is created, retain the 'this' pointer.
    2) Teach getCurrentThisType() to recognize it is within a generic lambda within an NSDMI/default-initializer and return the appropriate this type.

I chose to implement #2 (though I confess I do not have a compelling reason for choosing it over #1).

Richard Smith accepted the patch:
http://reviews.llvm.org/D3935

Thank you!



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

PR11410 - Confusing diagnostic when trailing array element tries to call deleted default constructor

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

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

Differential Revision: http://reviews.llvm.org/D3963

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

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

These intrinsics are special because they directly take a memory operand (AVX2
adds the register counterparts).  Typically, other non-memop intrinsics take
registers and then it's left to isel to fold memory operands.

In order to LICM intrinsics directly reading memory, we require that no stores
are in the loop (LICM) or that the folded load accesses constant memory
(MachineLICM).  When neither is the case we fail to hoist a loop-invariant
broadcast.

We can work around this limitation if we expose the load as a regular load and
then just implement the broadcast using the vector initializer syntax.  This
exposes the load to LICM and other optimizations.

At the IR level this is translated into a series of insertelements.  The
sequence is already recognized as a broadcast so there is no impact on the
quality of codegen.

_mm256_broadcast_pd and _mm256_broadcast_ps are not updated by this patch
because right now we lack the DAG-combiner smartness to recover the broadcast
instructions.  This will be tackled in a follow-on.

There will be completing changes on the LLVM side to remove the LLVM
intrinsics and to auto-upgrade bitcode files.

Fixes <rdar://problem/16494520>

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

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

Summary:
This adds documentation for -Rpass, -Rpass-missed and -Rpass-analysis.
It also adds release notes for 3.5.

Reviewers: rsmith

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D3730

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