Within Swift 6.0, we expanded an optimization for witness tables that
that allowed direct access to the witness table for conformances to
any protocol that can never have a witness table, rather than requiring
access through `swift_getWitnessTable` that might need to instantiate
the witness table.
The previous optimization only covered Objective-C protocols, but Swift
6.0 expanded that to marker protocols (such as `Sendable`) as well.
However, this constituted an API break when a Swift 6.0 compiler uses
a witness table that comes from a library built with an earlier version
of Swift, when the protocol inherits from Sendable but the conformance
to that protocol otherwise does not require an instantiation function.
In such cases, Swift 6.0 would generate code that directly accesses
the uninstantiated witness table symbol, which will have NULL entries
for any conformance in it that was considered "dependent" by the
earlier Swift compiler.
Introduce a deployment target check to guard the new optimization.
Specifically, when building for a deployment target that predates
Swift 6.0, treat conformances to marker protocols as if they might be
dependent (so the access patterns go through `swift_getWitnessTable`
for potential instantiation on older platforms). For newer deployment
targets, use the more efficent direct access pattern.
Fixes rdar://133157093.
A @_fixed_layout protocol exposes its witness table layout to
clients, which prevents re-ordering of requirements or adding
new requiremenst with a default.
When library evolution is enabled, we still emit method
descriptors even for @_fixed_layout protocols; this allows a
previously-resilient protocol to become @_fixed_layout as long
as the published layout matches the resilient layout in all
previously-shipped versions of the library.
If the conforming type is generic, we have to treat the conformance as
resilient if it is defined outside of the current module.
This is because it can resiliently change from being non-dependent
to dependent.
For a resilient protocol that has defaulted associated types, emit
default associated conformance witnesses that compute associated
conformances based on that default witness.
This completes the implementation of resilience protocols that
add new, defaulted associated types, rdar://problem/44167982.
Associated conformance descriptors are aliases that refer to associated
conformance requirements within a protocol descriptor’s list of
requirements. They will be used to provide protocol resilience against
the addition of new associated conformance requirements (which only makes
sense for newly-introduced, defaulted associated types).
When an associated type witness has a default, record that as part of
the protocol and emit a default associated type metadata accessor into the
default witness table. This allows a defaulted associated type to be
added to a protocol resiliently.
This is another part of rdar://problem/44167982, but it’s still very
limiting because the new associated type cannot have any conformances.
If a protocol witness table requires instantiation, the runtime
needs to call the witness table accessor when looking up the
conformance in swift_conformsToProtocol().
We had a bit of code for this already, but it wasn't fully
hooked up. Change IRGen to emit a reference to the witness table
accessor rather than the witness table itself if the witness
table needs instantiation, and add support to the runtime for
calling the accessor.
Now that we apply the callback with the correct generic signature, the
assert can go away. It was being triggered if the protocol extension was
defined in a different resilience domain; otherwise we prefer direct
access anyway.
Note that materializeForSet now has to be able to re-abstract Self when
invoking the callback, since we might have to go from a thin metatype
to a thick metatype.
