An "abstract" ProtocolConformanceRef is a conformance of a type
parameter or archetype to a given protocol. Previously, we would only
store the protocol requirement itself---but not track the actual
conforming type, requiring clients of ProtocolConformanceRef to keep
track of this information separately.
Record the conforming type as part of an abstract ProtocolConformanceRef,
so that clients will be able to recover it later. This is handled by a uniqued
AbstractConformance structure, so that ProtocolConformanceRef itself stays one
pointer.
There remain a small number of places where we create an abstract
ProtocolConformanceRef with a null type. We'll want to chip away at
those and establish some stronger invariants on the abstract conformance
in the future.
The Protocol field isn't really necessary, because the conformance
stores the protocol. But we do need the substituted subject type
of the requirement, just temporarily, until an abstract conformance
stores its own subject type too.
The "abstract conformance is just a ProtocolDecl" assumption is pretty
fundamental here, so we have to fudge a bit at the API boundary for now.
Eventually, LocalTypeDataKind should just contain a ProtocolConformanceRef
instead of duplicating the representation, however this would require
fixing various calls to LocalTypeDataKind::forAbstractProtocolWitnessTable()
which pass in a ProtocolDecl to pass in a ProtocolConformanceRef instead.
* [Concurrency] Detect non-default impls of isIsolatingCurrentContext
* [Concurrency] No need for trailing info about isIsolating... in conformance
* Apply changes from review
The NormalProtocolConformance APIs for checking for an explicitly-written
isolation on a conformance were easy to get to, and the real semantic
API was buried in the type checker, leading to some unprincipled
checking. Instead, create a central ProtocolConformance::getIsolation()
to get the (semantic) actor isolation, and let that be the only place
that will access the explicitly-written global actor isolation for a
conformance. Update all call sites appropriately.
Instead of using the `isolated P` syntax, switch to specifying the
global actor type directly, e.g.,
class MyClass: @MainActor MyProto { ... }
No functionality change at this point
When creating a specialized witness table, we need to get the right specialized conformance.
In IRGen don't emit associated conformance witness table entries if the protocol is not a class protocol.
In this case the associated type can never be used to create an existential. Therefore such a witness table entry is never used at runtime in embedded swift.
Fixes a compiler crash
rdar://146448091
Extend the metadata representation of protocol conformance descriptors
to include information about the global actor to which the conformance is
isolated (when there is one), as well as the conformance of that type to
the GlobalActor protocol. Emit this metadata whenever a conformance is
isolated.
When performing a conforms-to-protocol check at runtime, check whether
the conformance that was found is isolated. If so, extract the serial
executor for the global actor and check whether we are running on that
executor. If not, the conformance fails.
Noncopyable types may have user-defined code in their `deinit`s that requires
passing the type's generic parameters, so a box for a captured noncopyable type
needs to capture the generic environment even when the captured type is fixed-
layout. Fixes rdar://138958210.
When compiling with library evolution and a pre-Swift 6.0 deployment
target, a mismatch between the notion of resilience used for determining
whether a protocol that inherits Sendable might need to be treated as
"dependent" differed from how other parts of IR generation decided
whether to conformance should be considered as resilient. The
difference came when both the protocol and its conforming type are in
the same module as the user.
Switch over to the "is this conformance resilient?" query that takes
into account such conformances.
Fixes rdar://136586922.
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`.
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
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.
Some requirement machine work
Rename requirement to Value
Rename more things to Value
Fix integer checking for requirement
some docs and parser changes
Minor fixes
