then teach -Wreturn-type to handle the same.  Net effect:  we now correctly
handle noreturn attributes on member calls in the CFG.

llvm-svn: 131178

dynamic_cast correctly.

llvm-svn: 131177

This removes 2 errors when parsing MFC code with clang

Example:
class A {
    virtual void f() = 0 { }
}

llvm-svn: 131175

llvm-svn: 131170

llvm-svn: 131158

that they are C++0x extensions, and put them in the appropriate
group. We already support most of the semantics. Addresses
<rdar://problem/9407525>.

llvm-svn: 131153

Wait, what?

So, we run Clang (and LLVM) tests in an environment where the md5sum of the
input files becomes a component of the path. When testing the preprocessor,
the path becomes part of the output (in line directives). In this test, we
were grepping for the absence of "abc" in the output. When the stars aligned
properly, the md5sum component of the path contained "abc" and the test
failed. Oops.

llvm-svn: 131147

I've edited one diagnostic which would print "copy constructor" for copy
constructors and "constructor" for any other constructor. If anyone is
extremely enamored with this, it can be reinstated with a simple boolean
flag rather than calling getSpecialMember, which is inappropriate.

llvm-svn: 131143

llvm-svn: 131142

Elide __label__ declarations from the CFG.  This resolves a crash in CFGRecStmtDeclVisitor (crash in static analyzer).

llvm-svn: 131141

the semantic context referenced by the nested-name-specifier rather
than the syntactic form of the nested-name-specifier. The previous
incarnation was based on my complete misunderstanding of C++
[temp.expl.spec]. The latest C++0x working draft clarifies the
requirements here, and this rewrite is intended to follow that.

Along the way, improve source location information in the
diagnostics. For example, if we report that a specific type needs or
doesn't need a 'template<>' header, we dig out that type in the
nested-name-specifier and highlight its range.

Fixes: PR5907, PR9421, PR8277, PR8708, PR9482, PR9668, PR9877, and
<rdar://problem/9135379>.

llvm-svn: 131138

llvm-svn: 131132

llvm-svn: 131127

llvm-svn: 131126

llvm-svn: 131116

Focus is on default constructors for the time being. Currently the
exception specification and prototype are processed correctly. Codegen
might work but in all likelihood doesn't.

Note that due to an error, out-of-line defaulting of member functions is
currently impossible. It will continue to that until I muster up the
courage to admit that I secretly pray to epimetheus and that I need to
rework the way default gets from Parse -> Sema.

llvm-svn: 131115

reflect our new, more accurate AST.

llvm-svn: 131114

Also some -fdelayed-template-parsing test refactoring.

llvm-svn: 131113

unions. Fixes PR8326.

llvm-svn: 131109

llvm-svn: 131108

structs (impacts 32-bit only though).

llvm-svn: 131103

definitions to also include tag declarations. Fixes PR8151.

llvm-svn: 131102

hasTrivialDefaultConstructor() really really means it now.

Also implement a fun standards bug regarding aggregates. Doug, if you'd
like, I can un-implement that bug if you think it is truly a defect.

The bug is that non-special-member constructors are never considered
user-provided, so the following is an aggregate:

struct foo {
  foo(int);
};

It's kind of bad, but the solution isn't obvious - should

struct foo {
  foo (int) = delete;
};

be an aggregate or not?

Lastly, add a missing initialization to FunctionDecl.

llvm-svn: 131101

also consider whether any of the parameter types (as written, prior to
decay) are dependent. Fixes PR9880 and <rdar://problem/9408413>.

llvm-svn: 131099

modify the semantics slightly to accomodate default constructors (I
hope).

llvm-svn: 131087

when POSIXLY_COMPLIANT is set.
 - Patch by Dave Vasilevsky!

llvm-svn: 131084

rdar://problem/9391966

llvm-svn: 131080

llvm-svn: 131077

Necessary to parse MFC code.

llvm-svn: 131076

llvm-svn: 131075

llvm-svn: 131074

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

llvm-svn: 131068

llvm-svn: 131066

bit by allowing __weak and __strong to be added/dropped as part of
implicit conversions (qualification conversions in C++). A little
history: GCC lets one add/remove/change GC qualifiers just about
anywhere, implicitly. Clang did roughly the same before, but we
recently normalized the semantics of qualifiers across the board to
get a semantics that we could reason about (yay). Unfortunately, this
tightened the screws a bit too much for GC qualifiers, where it's
common to add/remove these qualifiers at will.

Overall, we're still in better shape than we were before: we don't
permit directly changing the GC qualifier (e.g., __weak -> __strong),
so type safety is improved. More importantly, we're internally
consistent in our handling of qualifiers, and the logic that allows
adding/removing GC qualifiers (but not adding/removing address
spaces!) only touches two obvious places.

Fixes <rdar://problem/9402499>.

llvm-svn: 131065

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

llvm-svn: 131057

Don't fail at parsing __declspec(property(get=get_func_name)). Just skip everything inside property() for now while we wait for the BoostPro people to provide a complete patch.

llvm-svn: 131053

bad assumptions about the alignment of the double* argument.

llvm-svn: 131052

http://msdn.microsoft.com/en-us/library/hzc8ytsz(v=VS.100).aspx

Microsoft doc claims this is a C++/CLI feature but it is really always enabled.
This removes 2 error when parsing MFC code with clang.

llvm-svn: 131051

llvm-svn: 131050