]> granicus.if.org Git - clang/commit
Don't allow clients to traverse into superclass synthesized properties
authorDaniel Dunbar <daniel@zuster.org>
Mon, 4 May 2009 04:10:48 +0000 (04:10 +0000)
committerDaniel Dunbar <daniel@zuster.org>
Mon, 4 May 2009 04:10:48 +0000 (04:10 +0000)
commit3715328021f69ed55e7b4cd65465fc761a8b6457
treea5c5be5e0fd100f2aa965fbce196c4acc86a0f1e
parent609e5c36af17bd951cba5c584a7580c575713686
Don't allow clients to traverse into superclass synthesized properties
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.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70822 91177308-0d34-0410-b5e6-96231b3b80d8
lib/AST/ASTContext.cpp
lib/CodeGen/CGObjCMac.cpp
test/CodeGenObjC/ivar-layout-64.m