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.
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.
It looks like this was the initial intent of 4ea82e1, but as implemented
it would still only scan the unresolved class list once. Since
unresolved_class_list represents the head and classes are pushed onto
the head, any classes added to the resolution list after resolution
started would be skipped.
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.
The protocols table and the class table will now grow as required. Protocols are now added to the protocols table as they are created, so you should get something sensible and introspectable back when you look up a protocol by name.
Note that concurrent resizing has not yet been implemented. That means that there is a hard limit on the number of classes that can be loaded. This is currently set to quite a small number for testing, to stress the hash table. If you're experiencing problems as a result, then please let me know and I will increase it.