in C++, taking into account conversions to the "composite pointer
type" so that we can compare, e.g., a pointer to a derived class to a
pointer to a base class. 

Also, upgrade the "comparing distinct pointer types" from a warning to
an error for C++, since this is clearly an error. Turns out that we
hadn't gone through and audited this code for C++, ever. 

Fixes <rdar://problem/6816420>.

llvm-svn: 70829

- Fix retain checker test failures.
- Update retain checker to have annotations override default summary effects, not completely redefine them.

llvm-svn: 70828

 - This implements gcc style Objective-C interface layout (I
   think). Currently it is always off, there is no functionality
   change unless this is passed.
   
   For the curious, the deal is that gcc lays out the fields of a
   subclass as if they were part of the superclass. That is, the
   subclass fields immediately follow the super class fields instead
   of being padded to the alignment of the superclass structure.

 - Currently gcc uses the tight layout in 32-bit and 64-bit modes, and
   llvm-gcc uses it in 32-bit only, for reasons which aren't clear
   yet. We probably want to switch to matching gcc, once this makes it
   through testing... my hope is that we can also fix llvm-gcc in
   order to maintain compatibility between the compilers.

llvm-svn: 70827

which is returned instead of a null pointer.  This helps centralize
the logic concerning "default effects".

llvm-svn: 70826

llvm-svn: 70825

We never compare summaries by their pointers, and we create only a
handful of them when analyzing a given function.

llvm-svn: 70824

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

 - The diagnostic is still poor, however. Doug, can you investigate?

 - Improved the test case to not depend on the file name, now it can
   be extended to actually check the formatting of the diagnostics
   (I'm hoping grep -A is portable here).

llvm-svn: 70807

stdint.h unless we are freestanding.

Any suggestions here are welcome.

llvm-svn: 70806

extension warning.

llvm-svn: 70805

llvm-svn: 70800

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

llvm-svn: 70798

llvm-svn: 70794

pasted token.

llvm-svn: 70793

llvm-svn: 70789

llvm-svn: 70786

llvm-svn: 70785

in C++. Fixes <rdar://problem/6815995>.

llvm-svn: 70784

llvm-svn: 70783

printing. Also, when we only need to truncate the line at the end,
make sure there is room for the ellipsis.

llvm-svn: 70781

llvm-svn: 70780

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: 70774

llvm-svn: 70773

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

invalidated by layout out the super class, we cannot cache the map
entry.

llvm-svn: 70693

 - These routines should now be independent of the Sema state.

 - This is nearly zero functionality change, the distinction only
   matters in the non-fragile ABI, and the consumers that care about
   this distinction should be using getASTObjCImplementationLayout.

llvm-svn: 70692

not the shadow structure.

llvm-svn: 70691

 - The difference from getASTObjCInterfaceLayout is that the computes
   the layout including synthesized ivars.

 - No functionality change, they currently both compute the same thing
   -- whether that includes synthesized ivars or not depends on when
   they get called!!!

llvm-svn: 70690

llvm-svn: 70689