llvm-svn: 132219

class type (or array thereof), eliminating some redundant checks
(thanks Eli!) and adding some tests where the behavior differs in
C++98/03 vs. C++0x.

llvm-svn: 132218

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

nontemplate in Sema::InstantiateTemplateDecl.

This should make the issue in PR10026 more visible, although it's not
going to fix it because something is violating this precondition.

llvm-svn: 132208

so that it looks at the initializer of a local variable of class type
(or array thereof) to determine whether it's just an implicit
invocation of the trivial default constructor. Fixes PR10034.

llvm-svn: 132191

llvm-svn: 132175

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

parameter types to be ill-formed. However, it relies on the
completeness of method parameter types when producing metadata, e.g.,
for a protocol, leading IR generating to crash in such cases.

Since there's no real way to tighten down the semantics of Objective-C
here without breaking existing code, do something safe but lame:
suppress the generation of metadata when this happens.

Fixes <rdar://problem/9123036>.

llvm-svn: 132171

llvm-svn: 132146

Change the include stack of "instantiated from" notes to fall under the control of f/fno-diagnostics-show-note-include-stack flags.  This should help with reducing diagnostic spew from macros instantiations.

llvm-svn: 132143

Add a fix-it and better error recovery for improperly nested namespaces.  This will give a better error message for cases such as "namespace foo::bar::baz {}" and a suggested fix-it of "namespace foo { namespace bar { namespace baz {} } }"

llvm-svn: 132138

llvm-svn: 132130

provide re-usable forms of the rest of the custom validation done here.
Still no functionality changed here.

With this it should be possible to have an expression-centric code path
and a type-centric code path which don't duplicate logic.

llvm-svn: 132118

information in the previous comment which was preserved and moved with
the vec_step implementation code.

llvm-svn: 132117

It has little overlap with other traits' requirements, so the resulting
code is actually simpler.

llvm-svn: 132116

traits which uses the information embedded in the expression. Use this
to simplify several interfaces which repeated information embedded in
the expression through explicit arguments. I added an assertion that the
only extra piece of data to come in from the parser matches what is
stored in the expression. No functionality change intended here.

Also cleaned up the doxygen comments for some of these methods and some
formatting oddities.

llvm-svn: 132115

makes it into a special member function. This is very bad and can lead
to all sorts of nastiness including implicit member functions violating
the One Definition Rule. This should probably be made ill-formed in a
later version of the standard, but for now we'll just warn.

llvm-svn: 132104

Skip extra copy from aggregate where it isn't necessary; rdar://problem/8139919 .  This shouldn't make much of a difference at -O3, but should substantially reduce the number of generated memcpy's at -O0.

Originally r130717, but was backed out due to an ObjC regression.

llvm-svn: 132102

static analyzer: when conservatively evaluating functions, don't invalidate the values of globals when the called function is strlen.

llvm-svn: 132100

llvm-svn: 132096

Pattern is not. Thanks Nick for catching this!

llvm-svn: 132089

behind implicit moves. We now correctly identify move constructors and
assignment operators and update bits on the record correctly. Generation
of implicit moves (declarations or definitions) is not yet supported.

llvm-svn: 132080

llvm-svn: 132077

llvm-svn: 132064

llvm-svn: 132060

llvm-svn: 132059

llvm-svn: 132058

Example:

typedef int TYPE;
class C {
  __if_exists(TYPE) {
     TYPE a;
  }
  __if_not_exists(TYPE) {
     this will never be parsed.
  }
};

llvm-svn: 132052

llvm-svn: 132049

Enhance retain/release checker to flag warnings when functions returning CG types do not follow the Core Foundation naming conventions.

llvm-svn: 132048

Patch by Matthieu Monrocq with tweaks by me to avoid StringRefs in the static
diagnostic data structures, which resulted in a huge global-var-init function.

Depends on llvm commit r132046.

llvm-svn: 132047

llvm-svn: 132034

llvm-svn: 132020

type that turns one type into another. This is used as the basis to
implement __underlying_type properly - with TypeSourceInfo and proper
behavior in the face of templates.

llvm-svn: 132017

llvm-svn: 132013

libprofile_rt.a. On Darwin, don't try to link -lgcov.

llvm-svn: 132006

llvm-svn: 132001

Patch by Dimitry Andric!

llvm-svn: 131990

Add new warning that warns when invoking 'delete' on a polymorphic, non-final, class without a virtual destructor.

Patch by Matthieu Monrocq!

llvm-svn: 131989

that the unevaluated subexpressions of &&, ||, and ? : are not
considered when determining whether the expression is a constant
expression. Also, turn the "used in its own initializer" warning into
a runtime-behavior warning, so that it doesn't fire when a variable is
used as part of an unevaluated subexpression of its own initializer.

Fixes PR9999.

llvm-svn: 131968