Refactor global decls to hold either a regular Decl or a CXXConstructorDecl + ctor type or a CXXDestructorDecl + dtor type.

llvm-svn: 70962

llvm-svn: 70951

objc_assign_global API when assigning to global
objective-c object pointer.

llvm-svn: 70939

compensating for super classes). This was making the reported class
sizes for empty classes very, very wrong.
 - Also, we now report the size info for an empty class like gcc (as
   the offset of the start, not as 0, 0).

 - Add a few more test cases we were mishandling before (padding bit
   field at end of struct, for example).

llvm-svn: 70938

layout.
 - This is much simpler / more efficient.

 - This also properly computes the size in the presence of bit-fields.

llvm-svn: 70916

function calls.  For a program like this:

#include <stdio.h>
static __inline__ __attribute__((always_inline)) 
int bar(int x) { return 4; }
int main() { 
  int X = bar(4);
  printf("%d\n", X);
}

clang was not outputing any debug info for the body of main().  This is
because the backend is getting confused by the region_start/end that clang
is emitting for block scopes.  For now, just disable these (matching llvm-gcc),
this stuff is in progress of rework anyway.

llvm-svn: 70889

"The attached diff fixes the //FIXME in message send to super.  This should now be faster, and works in the presence of class posing.  This is now the same approach as used in GCC (the earlier code was a quick hack to get something working)."

Patch by David Chisnall!

llvm-svn: 70877

The attached diff fixes the //FIXME in message send to super.  This
should now be faster, and works in the presence of class posing.  This
is now the same approach as used in GCC (the earlier code was a quick
hack to get something working).

llvm-svn: 70868

llvm-svn: 70835

llvm-svn: 70825

hopefully, this fixes PR4144 without any regressions.

llvm-svn: 70823

via CollectObjCIvars.
 - In places where we need them, we should have the implementation and
   access the properties through it.

This is a fairly substantial functionality change: 
 1. @encode no longer encodes synthesized ivars, ever.

 2. The ivar layout bitmap no longer encodes information for
    synthesized ivars in superclasses. Well, actually I had already
    broken that, but it is intentional now.

We are now differing substantially from llvm-gcc and gcc
here. However, in my opinion this fundamentally *must* work if
non-fragile classes are to work. Without this change, the result of
@encode and the ivar layout depend on the order that the
implementation is seen in a file (if it is in the same file with its
superclass). Since both scenarios should work the same, our behavior
is now consistent with gcc behavior as if an implementation is never
seen following an implementation of its superclass.

Note that #2 is only a functionality change when (A) an
implementation appears in the same translation unit with the
implementation of its superclass, and (B) the superclass has
synthesized ivars. My belief is that this situation does not occur in
practice.

I am not yet sure of the role/semantics of @encode when synthesized
ivars are present... it's use is fairly unsound in a non-fragile world.

llvm-svn: 70822

llvm-svn: 70813

llvm-svn: 70812

llvm-svn: 70810

ivar layout.
 - The layout needs access to synthesized ivars.

llvm-svn: 70798

llvm-svn: 70794

llvm-svn: 70789

llvm-svn: 70786

llvm-svn: 70785

llvm-svn: 70783

just computing it!

llvm-svn: 70779

llvm-svn: 70778

llvm-svn: 70777

llvm-svn: 70776

Lift up a size calculation and note some asymmetries.

llvm-svn: 70775

llvm-svn: 70771

struct.
 - We still need to do more lookup than necessary because ivars don't
   live in a reasonable DeclContext.

 - The only remaining client of the interface shadow struct is the
   ivar layout bitmap.

llvm-svn: 70756

decl. Only this routine will be suitable for computing the offset of a
synthesized ivar.
 - No functionality change.

llvm-svn: 70696

not the shadow structure.

llvm-svn: 70691

this fixes http://llvm.org/bugs/show_bug.cgi?id=3373#c20

llvm-svn: 70685

llvm-svn: 70684

llvm-svn: 70683

llvm-svn: 70680

the input.  This is part of PR3373.

llvm-svn: 70677

like bitfields.  incidentally llvm-gcc crashes on this sort of thing also. :)

llvm-svn: 70675

 - No functionality change.

llvm-svn: 70674

llvm-svn: 70672

processing the outputs, no functionality change.

llvm-svn: 70671

the runtime version number onto it, so that the debugger knows it's an objc
interface, not a C struct.  rdar://6848435

llvm-svn: 70618