gcc.

Fixes PR9886.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131182 91177308-0d34-0410-b5e6-96231b3b80d8

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



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131178 91177308-0d34-0410-b5e6-96231b3b80d8

dynamic_cast correctly.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131177 91177308-0d34-0410-b5e6-96231b3b80d8

This removes 2 errors when parsing MFC code with clang

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131175 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131170 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131158 91177308-0d34-0410-b5e6-96231b3b80d8

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


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131153 91177308-0d34-0410-b5e6-96231b3b80d8

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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131147 91177308-0d34-0410-b5e6-96231b3b80d8

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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131143 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131142 91177308-0d34-0410-b5e6-96231b3b80d8

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131141 91177308-0d34-0410-b5e6-96231b3b80d8

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>.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131138 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131132 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131127 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131126 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131116 91177308-0d34-0410-b5e6-96231b3b80d8

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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131115 91177308-0d34-0410-b5e6-96231b3b80d8

reflect our new, more accurate AST.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131114 91177308-0d34-0410-b5e6-96231b3b80d8

Also some -fdelayed-template-parsing test refactoring.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131113 91177308-0d34-0410-b5e6-96231b3b80d8

unions. Fixes PR8326.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131109 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131108 91177308-0d34-0410-b5e6-96231b3b80d8

structs (impacts 32-bit only though).


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131103 91177308-0d34-0410-b5e6-96231b3b80d8

definitions to also include tag declarations. Fixes PR8151.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131102 91177308-0d34-0410-b5e6-96231b3b80d8

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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131101 91177308-0d34-0410-b5e6-96231b3b80d8

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


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131099 91177308-0d34-0410-b5e6-96231b3b80d8

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131087 91177308-0d34-0410-b5e6-96231b3b80d8

when POSIXLY_COMPLIANT is set.
 - Patch by Dave Vasilevsky!

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131084 91177308-0d34-0410-b5e6-96231b3b80d8

rdar://problem/9391966



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131080 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131077 91177308-0d34-0410-b5e6-96231b3b80d8

Necessary to parse MFC code.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131076 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131075 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131074 91177308-0d34-0410-b5e6-96231b3b80d8

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


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131068 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131066 91177308-0d34-0410-b5e6-96231b3b80d8

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>.




git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131065 91177308-0d34-0410-b5e6-96231b3b80d8

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


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131060 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131057 91177308-0d34-0410-b5e6-96231b3b80d8

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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131053 91177308-0d34-0410-b5e6-96231b3b80d8

bad assumptions about the alignment of the double* argument.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131052 91177308-0d34-0410-b5e6-96231b3b80d8

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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@131051 91177308-0d34-0410-b5e6-96231b3b80d8