This cleans up handling of objects that are not reference counted and
makes their interactions with ARC more consistent. We should probably
generalise this somewhat - it currently special cases NSConstantString
and NSGlobalBlock, but it would be nice to have an API for constant
objects.
Coverage checking of the test suite showed that objc_disposeClassPair
wasn't tested at all, which then led to discovering that it didn't
unregister the class.
Several of the structures now end with an array of structures that may
have other fields added to them that the runtime doesn't know about yet
by a compiler. Rather than indexing into them directly, we must call an
accessor to find the correct address.
A few of the places where accesses were replaced were in functions where
it is safe because they only deal with versions of the structures that
are dynamically allocated (and will therefore have the correct size).
This was done to simplify future auditing: these fields should be
accessed directly only from the accessor functions in the header and
from the upgraders (currently in legacy.c).
Also fix a few bugs where the sizes weren't being filled in.
In the legact ABI, superclass pointers are initially set to strings
containing the superclass name and the runtime fixes them up. In the
new ABI, the compiler sets up the linkage directly.
We're now using a new class and category structure and auto-upgrading the old ones. Other changes:
- The Ivar structure now points to the ivar offset variable, so we can more easily find it.
- Categories can now add properties.
This probably didn't make a difference, but if we ended up
resolving a class as a result of resolving a subclass, then we'd previously go and explore an unrelated linked list for a bit.
The runtime was handling the message lookup correctly in this case, but only as a side-effect of the fallback code from when type-dependent dispatch is not possible. This resulted in a confusing warning message, telling you that you were calling a method with an incorrect signature, when the two signatures that it printed were the same.
This case is now handled correctly, so the warning disappears (unless you really are calling a method with the wrong signature and have TDD enabled).
Hence not all classes were previously resolved at load time.
Was breaking +forwardInvocation: because unresolved classes such as
GSFFInvocation were not receiving +load right when gnustep-base was loaded.
David Chisnall
David Chisnall
David Chisnall
theraven
thebeing
ericwa
qmathe