The main change here is to associate a witness table with a `ProtocolConformance` instead of a `RootProtocolConformance`.
A `ProtocolConformance` is the base class and can be a `RootProtocolConformance` or a `SpecializedProtocolConformance`.
For types like `Atomic` and `Mutex`, we want to know that even though they are
technically bitwise-takable, they differ from other bitwise-takable types until
this point because they are not also "bitwise-borrowable"; while borrowed,
they are pinned in memory, so they cannot be passed by value as a borrowed
parameter, unlike copyable bitwise-takable types. Add a bit to the value witness
table flags to record this.
Note that this patch does not include any accompanying runtime support for
propagating the flag into runtime-instantiated type metadata. There isn't yet
any runtime functionality that varies based on this flag, so that can
be implemented separately.
rdar://136396806
Motivated by need for protocol-based dynamic dispatch, which hasn't been possible in Embedded Swift due to a full ban on existentials. This lifts that restriction but only for class-bound existentials: Class-bound existentials are already (even in desktop Swift) much more lightweight than full existentials, as they don't need type metadata, their containers are typically 2 words only (reference + wtable pointer), don't incur copies (only retains+releases).
Included in this PR:
[x] Non-generic class-bound existentials, executable tests for those.
[x] Extension methods on protocols and using those from a class-bound existential.
[x] RuntimeEffects now differentiate between Existential and ExistentialClassBound.
[x] PerformanceDiagnostics don't flag ExistentialClassBound in Embedded Swift.
[x] WTables are generated in IRGen when needed.
Left for follow-up PRs:
[ ] Generic classes support
If a constrained extension has fewer conformance requirements
than the nominal type declaration, because some of the type
parameters of the nominal type are fixed to concrete types by
the extension, we would run into trouble because interface
type substitution does not correctly handle this case.
Applying an identity substitution map to an interface type
does not look up concrete types in the output generic
signature, so we get back a type parameter that is not valid.
getReducedType() has a hack to deal with this. I'd like to
get rid of the hack and fix interface type substitution to
do this correctly, but until then, this will do.
Fixes https://github.com/swiftlang/swift/issues/76479
Unless there is some meaningful code on the same line as an await call (e.g.
other parts of an expression), there should be no additional line entries
associated with that line on the continuation funclet.
This patch changes codegen to avoid emitting debug location for the "prologue" code
at the start of a funclet, instead of simply copying the debug location of the
split point.
The generality of the `AvailabilityContext` name made it seem like it
encapsulates more than it does. Really it just augments `VersionRange` with
additional set algebra operations that are useful for availability
computations. The `AvailabilityContext` name should be reserved for something
pulls together more than just a single version.
A change to the way we determined whether a protocol conformance is
"dependent" for marker protocols caused an ABI break for
Sendable-refining protocols built with pre-6.0 Swift compilers. The
fix for this issue (https://github.com/swiftlang/swift/pull/75769)
gated the change on deployment target.
The deployment target change fixed the original problem, then caused a
related issue when a project mixes deployment targets (pre-6.0 and
6.0+) with non-resilient protocols. Exempt non-resilient protocols from
this change so we get consistent behavior.
Fixes rdar://134953989.