- 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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70827 91177308-0d34-0410-b5e6-96231b3b80d8
which is returned instead of a null pointer. This helps centralize
the logic concerning "default effects".
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70826 91177308-0d34-0410-b5e6-96231b3b80d8
We never compare summaries by their pointers, and we create only a
handful of them when analyzing a given function.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70824 91177308-0d34-0410-b5e6-96231b3b80d8
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
- 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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70807 91177308-0d34-0410-b5e6-96231b3b80d8
printing. Also, when we only need to truncate the line at the end,
make sure there is room for the ellipsis.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70781 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70756 91177308-0d34-0410-b5e6-96231b3b80d8
decl. Only this routine will be suitable for computing the offset of a
synthesized ivar.
- No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70696 91177308-0d34-0410-b5e6-96231b3b80d8
- 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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70692 91177308-0d34-0410-b5e6-96231b3b80d8
- 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!!!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70690 91177308-0d34-0410-b5e6-96231b3b80d8
- This is somewhat cleaner and also fixes PR4063 for real, I had the
order wrong so we were just creating an empty dependency file.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70687 91177308-0d34-0410-b5e6-96231b3b80d8
Daniel Dunbar
Ted Kremenek
Eli Friedman
Anders Carlsson
Douglas Gregor
Anton Korobeynikov