implicitly-generated copy constructor. Previously, Sema would perform
some checking and instantiation to determine which copy constructors,
etc., would be called, then CodeGen would attempt to figure out which
copy constructor to call... but would get it wrong, or poke at an
uninstantiated default argument, or fail in other ways.

The new scheme is similar to what we now do for the implicit
copy-assignment operator, where Sema performs all of the semantic
analysis and builds specific ASTs that look similar to the ASTs we'd
get from explicitly writing the copy constructor, so that CodeGen need
only do a direct translation.

However, it's not quite that simple because one cannot explicit write
elementwise copy-construction of an array. So, I've extended
CXXBaseOrMemberInitializer to contain a list of indexing variables
used to copy-construct the elements. For example, if we have:

  struct A { A(const A&); };
  
  struct B {
    A array[2][3];
  };

then we generate an implicit copy assignment operator for B that looks
something like this:

  B::B(const B &other) : array[i0][i1](other.array[i0][i1]) { }

CodeGen will loop over the invented variables i0 and i1 to visit all
elements in the array, so that each element in the destination array
will be copy-constructed from the corresponding element in the source
array. Of course, if we're dealing with arrays of scalars or class
types with trivial copy-assignment operators, we just generate a
memcpy rather than a loop.

Fixes PR6928, PR5989, and PR6887. Boost.Regex now compiles and passes
all of its regression tests.

Conspicuously missing from this patch is handling for the exceptional
case, where we need to destruct those objects that we have
constructed. I'll address that case separately.

llvm-svn: 103079

not just the inner expression.  This is important if the expression has any
temporaries.  Fixes PR 7028.

Basically a symptom of really tragic method names.

llvm-svn: 102998

llvm-svn: 102889

llvm-svn: 102888

llvm-svn: 102887

llvm-svn: 102886

llvm-svn: 102885

llvm-svn: 102883

llvm-svn: 102882

llvm-svn: 102881

llvm-svn: 102880

llvm-svn: 102871

llvm-svn: 102870

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

llvm-svn: 102848

llvm-svn: 102846

llvm-svn: 102845

llvm-svn: 102842

llvm-svn: 102747

a class with virtual bases.  Just a patch until Sema starts (correctly) doing
most of this analysis.

Fixes PR 6622.

llvm-svn: 102692

llvm-svn: 102676

llvm-svn: 102674

llvm-svn: 102293

llvm-svn: 102289

llvm-svn: 102286

llvm-svn: 102285

RenameGetAddressOfBaseOfCompleteClass to GetAddressOfDirectBaseInCompleteClass to reflect that it only handles direct bases.

llvm-svn: 102284

llvm-svn: 102282

llvm-svn: 102281

DefineImplicitCopyConstructor now uses SetBaseOrMemberInitializers to create implicit base initializers. (Member initializers are still handled by CodeGenFunction::SynthesizeCXXCopyConstructor for now).

llvm-svn: 102279

llvm-svn: 102275

llvm-svn: 102274

llvm-svn: 102273

llvm-svn: 102272

Add a new GetAddressOfBaseClass overload that takes a base path and. Use it for derived-to-base casts.

llvm-svn: 102270

llvm-svn: 102007

llvm-svn: 101921

Fix a bug which triggered the assertion I added yesterday. Basically, when we initialize the vtable pointer for a virtual base, and there was another path from the most derived class to another base with the same class type, we would use the wrong base.

llvm-svn: 101911

llvm-svn: 101909