When doing a derived-to-base class through a virtual class, we don't have to get the vbase offset from the vtable if the derived class is marked final.

llvm-svn: 124523

more accurate, and makes it make sense for it to hold a delegating constructor
call.

llvm-svn: 123084

More anonymous struct/union redesign. This one deals with anonymous field used in a constructor initializer list:

struct X {
  X() : au_i1(123) {}
  union {
    int au_i1;
    float au_f1;
  };
};

clang will now deal with au_i1 explicitly as an IndirectFieldDecl.

llvm-svn: 120900

copy helper function and dtor of copied cxx objects
in dispose helper functions. __block variables
TBD next.

llvm-svn: 119011

Rename getBaseClassOffset to getBaseClassOffsetInBits and introduce a getBaseClassOffset which returns the offset in CharUnits. Do the same thing for getVBaseClassOffset.

llvm-svn: 117881

so that it's done in one place.

llvm-svn: 117386

ambiguous context.

llvm-svn: 116567

the bases are completely initialized.  This won't work --- base
initializer expressions can rely on the vtables having been set up.
Check for uses of 'this' in the initializers and force a vtable
initialization if found.

This might not be good enough;  we might need to extend this to handle
the possibility of arbitrary code finding an external reference to this
(not yet completely-constructed!) object and accessing through it,
in which case we'll probably find ourselves doing a lot more unnecessary
stores.

llvm-svn: 114153

slot.  The easiest way to do that was to bundle up the information
we care about for aggregate slots into a new structure which demands
that its creators at least consider the question.

I could probably be convinced that the ObjC 'needs GC' bit should
be rolled into this structure.
Implement generalized copy elision.  The main obstacle here is that
IR-generation must be much more careful about making sure that exactly

llvm-svn: 113962

llvm-svn: 111716

Emit a stop point for delegate constructor call. This gives user a chance to step into constructor body.

llvm-svn: 110853

This takes some trickery since CastExpr has subclasses (and indeed,
is abstract).

Also, smoosh the CastKind into the bitfield from Expr.

Drops two words of storage from Expr in the common case of expressions
which don't need inheritance paths.  Avoids a separate allocation and
another word of overhead in cases needing inheritance paths.  Also has
the advantage of not leaking memory, since destructors for AST nodes are
never run.

llvm-svn: 110507

commits.

llvm-svn: 109000

using a lazy cleanup.

llvm-svn: 108994

llvm-svn: 108989

llvm-svn: 108979

lazy cleanups.

llvm-svn: 108978

initializer of (). Make sure to use a simple memset() when we can, or
fall back to generating a loop when a simple memset will not
suffice. Fixes <rdar://problem/8212208>, a regression due to my work
in r107857.

llvm-svn: 108977

mostly in avoiding unnecessary work at compile time but also in producing more
sensible block orderings.

Move the destructor cleanups for local variables over to use lazy cleanups.
Eventually all cleanups will do this;  for now we have some awkward code
duplication.

Tell IR generation just to never produce landing pads in -fno-exceptions.
This is a much more comprehensive solution to a problem which previously was
half-solved by checks in most cleanup-generation spots.

llvm-svn: 108270

rethrow.  Fixes rdar://problem/7696603

llvm-svn: 107757

self-host.  Hopefully these results hold up on different platforms.  

I tried to keep the GNU ObjC runtime happy, but it's hard for me to test.
Reimplement how clang generates IR for exceptions.  Instead of creating new
invoke destinations which sequentially chain to the previous destination,
push a more semantic representation of *why* we need the cleanup/catch/filter
behavior, then collect that information into a single landing pad upon request.

Also reorganizes how normal cleanups (i.e. cleanups triggered by non-exceptional
control flow) are generated, since it's actually fairly closely tied in with
the former.  Remove the need to track which cleanup scope a block is associated
with.

Document a lot of previously poorly-understood (by me, at least) behavior.

The new framework implements the Horrible Hack (tm), which requires every
landing pad to have a catch-all so that inlining will work.  Clang no longer
requires the Horrible Hack just to make exceptions flow correctly within
a function, however.  The HH is an unfortunate requirement of LLVM's EH IR.

llvm-svn: 107631

CXXRecordDecl::getDestructor(); no functionality change.

llvm-svn: 107394

llvm-svn: 106949

llvm-svn: 105647

llvm-svn: 105646

actually care about it. Fixes PR7291.

llvm-svn: 105404

llvm-svn: 104778

llvm-svn: 104446

llvm-svn: 104390

Rename CodeGenFunction::EmitMemSetToZero to EmitNullInitialization. Handle setting null data member pointers correctly. Fixes PR7139.

llvm-svn: 104387

class initialization, drill down through an arbitrary number of anonymous
records.

llvm-svn: 104310

fixing PR7063.

llvm-svn: 103171

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