llvm-svn: 70952

 ns_ownership_returns -> ns_returns_owned
 ns_ownership_retain -> ns_retains
 ns_ownership_release -> ns_releases
 cf_ownership_retain ->  cf_retains
 cf_ownership_release -> cf_releases

llvm-svn: 70949

llvm-svn: 70941

llvm-svn: 70940

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

llvm-svn: 70918

layout.
 - This is much simpler / more efficient.

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

llvm-svn: 70916

llvm-svn: 70901

llvm-svn: 70897

'==' and '!=' (some code in the '!=' was not replicated in the '==' code,
causing some constraints to get lost).

llvm-svn: 70885

'objc_ownership_cfretain' -> 'cf_ownership_retain'
'objc_ownership_cfrelease' -> 'cf_ownership_release'

Motivation: Core Foundation objects can be used in isolation from Objective-C,
and this forces users to reason about the separate semantics of CF objects. More
Sema support pending.

llvm-svn: 70884

llvm-svn: 70883

return type and the selector.  This is inconsistent with C functions
(where such attributes would be placed on the return type, not the the
FunctionDecl), and is inconsistent with what people are use to seeing.

llvm-svn: 70878

rather odd when truncated.

llvm-svn: 70866

test into a separate file to monitor the fact that BasicStoreManager
passes the test.

llvm-svn: 70859

no-outofbounds.c still fails. Previously it passed because the array index
is mistakenly a loc::ConcreteInt.

llvm-svn: 70844

Test now passes.  I'll hold off merging it with the BasicStore test until we know this is a stable change.

llvm-svn: 70837

StoreManager: Handle casts from one element region to another.
Update test cases.

llvm-svn: 70836

llvm-svn: 70834

'ElementRegion' on top of the VarRegion for 'x'.  This causes the test
case xfail_wine_crash.c to now pass for BasicStoreManager.  It doesn't
crash for RegionStoreManager either, but reports a bogus unintialized
value warning.

llvm-svn: 70832

ElementRegion.  I also removed 'ElementRegion::getArrayRegion',
although we may need to add this back.

This breaks a few test cases with RegionStore:
- 'array-struct.c' triggers an infinite recursion in RegionStoreManager.  Need to investigate.
- misc-ps.m triggers a failure with RegionStoreManager as we now get the diagnostic:
  'Line 159: Uninitialized or undefined return value returned to caller.'
  
There were a bunch of places that needed to be edit
RegionStoreManager, and we may not be passing all the correct 'element
types' down from GRExprEngine.

Zhongxing: When you get a chance, could you review this?  I could have
easily screwed up something basic in RegionStoreManager.

llvm-svn: 70830

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

llvm-svn: 70825

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

llvm-svn: 70816

llvm-svn: 70809

 - 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

extension warning.

llvm-svn: 70805

llvm-svn: 70800

llvm-svn: 70799

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

llvm-svn: 70798

llvm-svn: 70797

llvm-svn: 70796

llvm-svn: 70795

llvm-svn: 70794

pasted token.

llvm-svn: 70793

llvm-svn: 70791

llvm-svn: 70786