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

non-POD/non-trivial object throuugh a C-style varargs. The warning
itself was default-mapped to error, but can be downgraded, but we were
treating it in Sema like a hard error, silently dropping the call.

Instead, treat this problem like a warning, and do what the warning
says we do: abort at runtime. To do so, we fake up a __builtin_trap()
expression that gets evaluated as part of the argument.

llvm-svn: 131805

Type::isUnsignedIntegerOrEnumerationType(), which are like
Type::isSignedIntegerType() and Type::isUnsignedIntegerType() but also
consider the underlying type of a C++0x scoped enumeration type.

Audited all callers to the existing functions, switching those that
need to also handle scoped enumeration types (e.g., those that deal
with constant values) over to the new functions. Fixes PR9923 /
<rdar://problem/9447851>.

llvm-svn: 131735

Reapply r121528, fixing PR9941 by delaying the exception specification check for destructors until the class is complete and destructors have been adjusted.

llvm-svn: 131632

other things, libcxx not building.

llvm-svn: 131573

llvm-svn: 131528

optimization for abstract classes;  there was a misunderstanding, and
it turns out that there are no kexts which rely on this.

llvm-svn: 131489

llvm-svn: 131435

reasons that honestly really, really need to be looked into.

llvm-svn: 131434

optimization. Make sure to require a vtable when trying to get the address
of a VTT, otherwise we would never end up emitting the VTT.

llvm-svn: 131400

operators;  their semantics are guaranteed by the language.

If someone wants to argue that freestanding compiles shouldn't recognize
this, I might be convinceable.

llvm-svn: 131395

llvm-svn: 131385

It can be larger, it can be smaller, it can be signed, whatever.  Handle
all the crazy cases with grace and spirit.

llvm-svn: 131378

llvm-svn: 131372

that the destructor body is trivial and that all member variables also have either
trivial destructors or trivial destructor bodies, we don't need to initialize the
vtable pointers since no virtual member functions will be called on the destructor.

Fixes PR9181.

llvm-svn: 131368

constant, also consider whether it's a class type that has any mutable
fields. If so, it can't be a global constant.

llvm-svn: 131276

complete destructors for abstract classes unless the destructor is virtual
and thus needs to be in the vtable.

llvm-svn: 131068

type, so long as it is known to have a constant initializer and the
class type is a POD class. Fixes <rdar://problem/9306265>.

llvm-svn: 131060

Add an implementation of thunks for varargs methods.  The implementation is a bit messy, but it is correct as long as the method in question doesn't use indirect gotos.  A couple of possible alternative implementations are outlined in FIXME's in this patch. rdar://problem/8077308 .

llvm-svn: 130993

llvm-svn: 130953

if they match that production, i.e. if they're template type parameters
or decltypes (or, as an obvious case not yet described in the ABI document,
if they're template template parameters applied to template arguments).

llvm-svn: 130824

llvm-svn: 130813

the body of a delegating constructor call.

This means that the delegating constructor implementation should be
complete and correct, though there are some rough edges (diagnostic
quality with the cycle detection and using a deleted destructor).

llvm-svn: 130803

FIXME: It would crash with -integrated-as. Implement -g on MCCOFF.
llvm-svn: 130682

This test seeks a verbose comment in output. By default, "-integrated-as" sets verbose-asm. Cygming is not ready for -integrated-as yet.

llvm-svn: 130681

parameter node and use this to correctly mangle parameter
references in function template signatures.

A follow-up patch will improve the storage usage of these
fields;  here I've just done the lazy thing.

llvm-svn: 130669

As far as I know, this implementation is complete but might be missing a
few optimizations. Exceptions and virtual bases are handled correctly.

Because I'm an optimist, the web page has appropriately been updated. If
I'm wrong, feel free to downgrade its support categories.

llvm-svn: 130642

-C++ objects with user-declared constructor don't need zero'ing.
-We can zero-initialize arrays of C++ objects in "bulk" now, in which case don't zero-initialize each object again.

llvm-svn: 130453

that a non-trivial C++ constructor gets called.

Fixes rdar://9347552 & http://llvm.org/PR9801

llvm-svn: 130421

worked out.

llvm-svn: 130376

make sure to mark the destructor.  This normally isn't required,
because the destructor should have been marked as part of the
declaration of the local, but it's necessary when the variable
is a parameter because it's the call sites that are responsible
for those destructors.

llvm-svn: 130372