Add support for the weakref attribute. We still produce "alias weak" as llvm-gcc does, but are more strict on what uses of weakref we accept.

llvm-svn: 96992

of the block descriptor field.  This field is the ObjC style @encode
signature of the implementation function, and was to this point
conditionally provided in the block literal data structure.  That
provisional support is removed.

Additionally, eliminate unused enumerations for the block literal flags field.
The first shipping ABI unconditionally set (1<<29) but this bit is unused
by the runtime, so the second ABI will unconditionally have (1<<30) set so
that the runtime can in fact distinguish whether the additional data is
present or not.

llvm-svn: 96989

rewriting problem. Fixes radar 7680953.

llvm-svn: 96987

pointer (for defensive programming).  This matches the behavior with
assigning NULL to a regular pointer.  Fixes <rdar://problem/7631278>.

llvm-svn: 96985

that refer to an undefined class.

llvm-svn: 96976

the result is integral.  Fixes <rdar://problem/7676608>.

llvm-svn: 96970

llvm-svn: 96962

llvm-svn: 96961

llvm-svn: 96958

llvm-svn: 96941

llvm-svn: 96897

the canonical calling conventions instead of comparing the raw calling
conventions directly. Fixes PR6361.

llvm-svn: 96895

to libAnalysis (with only the error reporting in libSema).

llvm-svn: 96893

llvm-svn: 96892

__alignof__ operator, make sure to take into account the packed alignment
of the struct/union/class itself. Matches GCC's behavior and fixes PR6362.

llvm-svn: 96884

llvm-svn: 96883

More fixes. Don't try to emit a virtual base vtable if the virtual base in question is a primary virtual base of some other base.

llvm-svn: 96881

Always emit vcall offset for the primary base, not only if it's virtual. Remove a debug printf, and add the test case that now passes.

llvm-svn: 96880

Simplify the vcall offset calculation and make it give the correct answers :) My test case now has the right values but in the wrong order.

llvm-svn: 96877

More work on vcall offsets. We now emit the right number of vcall offsets in my local test case, but not the right values.

llvm-svn: 96874

and into libAnalysis.

llvm-svn: 96872

llvm-svn: 96855

llvm-svn: 96853

llvm-svn: 96850

llvm-svn: 96848

No functionality change.

llvm-svn: 96847

1) emit base destructors as aliases to their unique base class destructors
under some careful conditions.  This is enabled for the same targets that can
support complete-to-base aliases, i.e. not darwin.

2) Emit non-variadic complete constructors for classes with no virtual bases
as calls to the base constructor.  This is enabled on all targets and in
theory can trigger in situations that the alias optimization can't (mostly
involving virtual bases, mostly not yet supported).

These are bundled together because I didn't think it worthwhile to split them,
not because they really need to be.

llvm-svn: 96842

C++98/03 and C++0x, since the '0x semantics break valid C++98/03
code. This new mess is tracked by core issue 399, which is still
unresolved.

Fixes PR6358 and PR6359.

llvm-svn: 96836

llvm-svn: 96819

itself rewritten. Radar 7669784.

llvm-svn: 96798

declaration. This is the trivial part of PR6365.

llvm-svn: 96792

llvm-svn: 96788

between cv1 T* and cv2 T*.

llvm-svn: 96787

CLANG_VTABLE_DEBUG.

llvm-svn: 96785

since they may not have normal identifiers for names. Fixes PR6369.

llvm-svn: 96784

not be guaranteed.

llvm-svn: 96782

llvm-svn: 96772

errors, e.g.:

t.c:1:21: error: redefinition of parameter 'x'
int test(int x, int x);
                    ^
t.c:1:14: note: previous declaration is here
int test(int x, int x);
             ^

llvm-svn: 96769

fixing up a few callers that thought they were propagating NoReturn
information but were in fact saying something about exception
specifications.

llvm-svn: 96766

  typedef int Int;
  int *p;
  p->Int::~Int();

This weakens the invariant that the only types in nested-name-specifiers are tag types (restricted to class types in C++98/03). However, we weaken this invariant as little as possible, accepting arbitrary types in nested-name-specifiers only when we're in a member access expression that looks like a pseudo-destructor expression.

llvm-svn: 96743