llvm-svn: 102890

llvm-svn: 102889

llvm-svn: 102888

llvm-svn: 102887

llvm-svn: 102886

llvm-svn: 102885

llvm-svn: 102884

llvm-svn: 102883

llvm-svn: 102882

llvm-svn: 102881

llvm-svn: 102880

Add an enum to CXXConstructExpr so we can determine if the construction expression constructs a non-virtual or virtual base.

llvm-svn: 102879

llvm-svn: 102871

llvm-svn: 102870

llvm-svn: 102863

llvm-svn: 102862

assignment operators. 

Previously, Sema provided type-checking and template instantiation for
copy assignment operators, then CodeGen would synthesize the actual
body of the copy constructor. Unfortunately, the two were not in sync,
and CodeGen might pick a copy-assignment operator that is different
from what Sema chose, leading to strange failures, e.g., link-time
failures when CodeGen called a copy-assignment operator that was not
instantiation, run-time failures when copy-assignment operators were
overloaded for const/non-const references and the wrong one was
picked, and run-time failures when by-value copy-assignment operators
did not have their arguments properly copy-initialized.

This implementation synthesizes the implicitly-defined copy assignment
operator bodies in Sema, so that the resulting ASTs encode exactly
what CodeGen needs to do; there is no longer any special code in
CodeGen to synthesize copy-assignment operators. The synthesis of the
body is relatively simple, and we generate one of three different
kinds of copy statements for each base or member:

  - For a class subobject, call the appropriate copy-assignment
    operator, after overload resolution has determined what that is.
  - For an array of scalar types or an array of class types that have
    trivial copy assignment operators, construct a call to
    __builtin_memcpy.
  - For an array of class types with non-trivial copy assignment
    operators, synthesize a (possibly nested!) for loop whose inner
    statement calls the copy constructor.
  - For a scalar type, use built-in assignment.

This patch fixes at least a few tests cases in Boost.Spirit that were
failing because CodeGen picked the wrong copy-assignment operator
(leading to link-time failures), and I suspect a number of undiagnosed
problems will also go away with this change.

Some of the diagnostics we had previously have gotten worse with this
change, since we're going through generic code for our
type-checking. I will improve this in a subsequent patch.

llvm-svn: 102853

llvm-svn: 102851

llvm-svn: 102849

llvm-svn: 102848

llvm-svn: 102847

llvm-svn: 102846

llvm-svn: 102845

llvm-svn: 102842

information required to implicitly define a C++ special member
function. Use it rather than explicitly setting CurContext on entry
and exit, which is fragile. 

Use this RAII object for the implicitly-defined default constructor,
copy constructor, copy assignment operator, and destructor.

llvm-svn: 102840

llvm-svn: 102839

llvm-svn: 102837

Used this in CGObjCGNU to attach metadata about message sends to permit speculative inlining.

llvm-svn: 102833

llvm-svn: 102825

already knows what context it's looking in.  Just pass that context in
instead of (questionably) recalculating it.

llvm-svn: 102818

llvm-svn: 102811

more resilient to bad code.

llvm-svn: 102793

(C) API, and will likely grow further in this direction in the future.

llvm-svn: 102779

fatal error has occurred.

llvm-svn: 102778

parameter with pointer-to-member type, we may have to perform a
qualification conversion, since the pointee type of the parameter
might be more qualified than the pointee type of the argument we form
from the declaration. Fixes PR6986.

llvm-svn: 102777

access.  Fixes an assertion.

Fixes rdar://problem/7927811.  Too lazy to reduce a test case.

llvm-svn: 102776

constant expression in C. 

llvm-svn: 102762

llvm-svn: 102748

llvm-svn: 102747

of the mapping from local declarations to their instantiated
counterparts during template instantiation. Previously, we tried to do
some unholy merging of local instantiation scopes that involved
storing a single hash table along with an "undo" list on the
side... which was ugly, and never handled function parameters
properly.

Now, we just keep separate hash tables for each local instantiation
scope, and "combining" two scopes means that we'll look in each of the
combined hash tables. The combined scope stack is rarely deep, and
this makes it easy to avoid the "undo" issues we were hitting. Also,
I've simplified the logic for function parameters: if we're declaring
a function and we need the function parameters to live longer, we just
push them back into the local instantiation scope where we need them. 

Fixes PR6990.

llvm-svn: 102732