Objective-C class references (which show up in the __objc_classrefs
section) are always coalesced by the linker. When we relatively
address them (which occurs in protocol conformance records), the
linker may compute the relative offset *before* coalescing, leading to
an incorrect result. The net effect is a protocol conformance record
that applies to the wrong Objective-C class, causing all sorts of
runtime mayhem.
Switch relatively-addressed Objective-C classes over to using the
Objective-C runtime name of the class. It's a less efficient encoding
(since we need to go through objc_lookUpClass), but it avoids the
linker bug.
Fixes rdar://problem/46428085 by working around the linker bug.
Avoid a temporary file and executing FileCheck multiple types and prefer
multiple check prefixes and streaming. Additionally, enable some of
previously XFAIL'ed tests on Linux as well as tests that were marked as
requiring Objective-C interop.
Within conformance records, reference Objective-C class objects
indirectly so the runtime can update those references appropriately.
We don't need to do this for classes with Swift metadata.
Make all OBJC_CLASS_REF symbols object-local using "\01l", which
prevents the linker from producing incorrect relative addresses.
Fixes the ABI-affecting part of rdar://problem/36310179.
Within conformance records, reference Objective-C class objects
indirectly so the runtime can update those references appropriately.
We don't need to do this for classes with Swift metadata.
Fixes the ABI-affecting part of rdar://problem/36310179.
Emit protocol conformance descriptors as separate symbols, rather than
inlining them within the section for protocol conformance records. We
want separate symbols for protocol conformances both because it is easier
to make them variable-length (as required for conditional
conformances) and because we want to reference them from witness
tables (both of which are coming up).
Within conformance records, reference Objective-C class objects
indirectly so the runtime can update those references appropriately.
We don't need to do this for classes with Swift metadata.
This gives big code size wins for unused types and also for types, which are never used in a generic context.
Also it reduces the amount of symbols in the symbol table.
The size wins heavily depend on the project. I have seen binary size reductions from 0 to 20% on real world projects.
rdar://problem/30119960
