llvm-svn: 134831

  - Emit default-initialization of arrays that were partially initialized
    with initializer lists with a loop, rather than emitting the default
    initializer N times;
  - support destroying VLAs of non-trivial type, although this is not
    yet exposed to users; and
  - support the partial destruction of arrays initialized with
    initializer lists when an initializer throws an exception.

llvm-svn: 134784

instantiating functions.

Fixes PR10272.

llvm-svn: 134491

variadic argument pack expansions as having changed, rather than doing
it for each changed expansion, which leaves out zero-argument packs
with catastrophic consequences.

Fixes PR10260.

llvm-svn: 134483

initializer. Previously, we only used guard variables for weak static
data members. Fixes <rdar://problem/9692249>.

llvm-svn: 134266

llvm-svn: 134262

trivial default constructors. This generated-code regression was
caused by r131796, which had simplified the handling of default
initialization in Sema. Fixes <rdar://problem/9694300>.

llvm-svn: 134260

This is kindof questionable but seems to do more-or-less the right thing.
This is not a particularly friendly part of the ABI.

llvm-svn: 134227

type/expression/template argument/etc. is instantiation-dependent if
it somehow involves a template parameter, even if it doesn't meet the
requirements for the more common kinds of dependence (dependent type,
type-dependent expression, value-dependent expression).

When we see an instantiation-dependent type, we know we always need to
perform substitution into that instantiation-dependent type. This
keeps us from short-circuiting evaluation in places where we
shouldn't, and lets us properly implement C++0x [temp.type]p2.

In theory, this would also allow us to properly mangle
instantiation-dependent-but-not-dependent decltype types per the
Itanium C++ ABI, but we aren't quite there because we still mangle
based on the canonical type in cases like, e.g.,

  template<unsigned> struct A { };
  template<typename T>
    void f(A<sizeof(sizeof(decltype(T() + T())))>) { }
  template void f<int>(A<sizeof(sizeof(int))>);

and therefore get the wrong answer.

llvm-svn: 134225

that serve as the base template name of an unresolved-name to
be mangled as a substitution.

llvm-svn: 134213

We don't pass classes with a copy-constructor or destructor byval, so the address takes up an integer register (if one is available).  Make sure the x86-64 ABI implementation takes that into account properly.

The fixed implementation is compatible with the implementation both gcc and llvm-gcc use.

rdar://9686430 . (This is the issue that was reported in the thread "[LLVMdev] Segfault calling LLVM libs from a clang-compiled executable".)

llvm-svn: 134059

llvm-svn: 134011

for explicit specializations with their own explicit visibility.

llvm-svn: 133958

for the '(' and ')' around the initializer unless we actually have an
initializer. Fixes PR10197, an issue where we were value-initializing
rather than default-initializing.

llvm-svn: 133913

arithmetic on a VLA as 'nsw', per discussion with djg, and
implement pointer arithmetic (other than array accesses) and
pointer subtraction for VLA types.

llvm-svn: 133855

llvm-svn: 133842

not sizes;  so that we use well-typed allocas;  and so that we
properly recurse through the full set of variably-modified types.

llvm-svn: 133827

use the unresolved-name production correctly.

llvm-svn: 133554

MaterializeTemporaryExpr captures a reference binding to a temporary
value, making explicit that the temporary value (a prvalue) needs to
be materialized into memory so that its address can be used. The
intended AST invariant here is that a reference will always bind to a
glvalue, and MaterializeTemporaryExpr will be used to convert prvalues
into glvalues for that binding to happen. For example, given

  const int& r = 1.0;

The initializer of "r" will be a MaterializeTemporaryExpr whose
subexpression is an implicit conversion from the double literal "1.0"
to an integer value. 

IR generation benefits most from this new node, since it was
previously guessing (badly) when to materialize temporaries for the
purposes of reference binding. There are likely more refactoring and
cleanups we could perform there, but the introduction of
MaterializeTemporaryExpr fixes PR9565, a case where IR generation
would effectively bind a const reference directly to a bitfield in a
struct. Addresses <rdar://problem/9552231>.

llvm-svn: 133521

ConvertType on InitListExprs as they are being converted.  This is
needed for a forthcoming patch, and improves the IR generated anyway
(see additional type names in testcases). 

This patch also converts a bunch of std::vector's in CGObjCMac to use
C arrays.  There are a ton more that should be converted as well.

llvm-svn: 133413

static initializer check, as required by the Itanium ABI.

llvm-svn: 133250

C++, which means:
  - binding the temporary as needed in Sema, so that we generate the
  appropriate call to the destructor, and
  - emitting the compound literal into the appropriate location for
  the aggregate, rather than trying to emit it as a temporary and
  memcpy() it.

Fixes PR10138 / <rdar://problem/9615901>.

llvm-svn: 133235

operators, don't make an initializer or sub-operation for zero-width
bitfields.

llvm-svn: 133221

llvm-svn: 133073

llvm-svn: 133011

llvm-svn: 132945

llvm-svn: 132878

PR10120: Make CodeGenModule::getVTableLinkage use NamedDecl::getLinkage to determine whether the vtable should be externally visible, instead of a rough approximation of it which messes up with templates.

While I'm here, zap the other user of isInAnonymousNamespace outside of Decl.cpp.

llvm-svn: 132861

llvm-svn: 132659

llvm-svn: 132623

llvm-svn: 132600

llvm-svn: 132357

  return f() || -1;

where the user meant to write '|'.

This bootstraps without any additional warnings.

Patch by Richard Trieu.

llvm-svn: 132327

It's quite likely that this will explode, but I need to know how. :)

llvm-svn: 132269

llvm-svn: 132219

to be careful to emit landing pads that are always prepared to handle a
cleanup path.  This is correct mostly because of the fix to the LLVM
inliner, r132200.

llvm-svn: 132209

within class templates when they are necessary to complete the type of
the member. The canonical example is code like:

  template <typename T> struct S {
    static const int arr[];
    static const int x;
    static int f();
  };

  template <typename T> const int S<T>::arr[] = { 1, 2, 3 };
  template <typename T> const int S<T>::x = sizeof(arr) / sizeof(arr[0]);
  template <typename T> int S<T>::f() { return x; }

  int x = S<int>::f();

We need to instantiate S<T>::arr's definition to pick up its initializer
and complete the array type. This involves new code to specially handle
completing the type of an expression where the type alone is
insufficient. It also requires *updating* the expression with the newly
completed type. Fortunately, all the other infrastructure is already in
Clang to do the instantiation, do the completion, and prune out the
unused bits of code that result from this instantiation.

This addresses the initial bug in PR10001, and will be a step to
fleshing out other cases where we need to work harder to complete an
expression's type. Who knew we still had missing C++03 "features"?

llvm-svn: 132172

issues and also add a test.

We should now handle defaulted members of templates properly. No
comment as to whether or not this also holds for templated functions,
but defaulting those is kind of insane.

llvm-svn: 131938

fixes PR9965, but we're not out of the water yet, as we do not
successfully handle out-of-line definitions, due to my utter
misunderstanding of how we manage templates.

llvm-svn: 131920

code generator will do it.  With this patch, clang compiles the example
in PR9794 to not have an alloca temporary.

llvm-svn: 131881