We already need to track the inverses separate from the members in a
ProtocolCompositionType, since inverses aren't real types. Thus, the
only purpose being served by InverseType is to be eliminated by
RequirementLowering when it appears in a conformance requirement.
Instead, we introduce separate type InverseRequirement just to keep
track of which inverses we encounter to facilitate cancelling-out
defaults and ensuring that the inverses are respected after running
the RequirementMachine.
`any Sendable` should be considered Objective-C capable just like
it's protocol composition with other Objective-C capable types.
Resolves: rdar://102728938
Previously, inverses were only accounted-for in inheritance clauses.
This batch of changes handles inverses appearing in other places, like:
- Protocol compositions
- `some ~Copyable`
- where clauses
with proper attribution of default requirements in their absence.
This is preparation for supporting parameterized protocols in
protocol compositions. The `sameTypeRequirements` field will
probably have to go; it's just not general enough to capture
what we want. That's assuming that we keep ExistentialLayout
in the long term at all, of course.
More groundwork for protocols with superclass constraints.
In several places we need to distinguish between existential
types that have a superclass term (MyClass & Proto) and
existential types containing a protocol with a superclass
constraint.
This is similar to how I can write 'AnyObject & Proto', or
write 'Proto1 & Proto2' where Proto1 has an ': AnyObject'
in its inheritance clause.
Note that some of the usages will be revisited later as
I do more refactoring and testing. This is just a first pass.
Also, make ExistentialLayout non-self-referential, by moving that logic to the
point where it is used. The construction of the one-element-ArrayRef is so cheap
that it doesn't need to be cached.
There were various problems with layout constraints either
being ignored or handled incorrectly. Now that I've exercised
this support with an upcoming patch, there are some fixes
here.
Also, introduce a new ExistentialLayout::getLayoutConstriant()
which returns a value for existentials which are class-constrained
but don't have a superclass or any class-constrained protocols;
an example would be AnyObject, or AnyObject & P for some
non-class protocol P.
NFC for now, since these layout-constrained existentials cannot
be constructed yet.
This consolidates calculations which need to look at every
protocol in an existential type. Soon we will also have to
deal with superclass constrained existentials, so start
updating call sites that look at all protocols to use the
new ExistentialLayout and correctly handle a class constraint
as well.
Also, eventually I will kill off the AnyObject protocol and
model it as a protocol composition with no protocols or
superclass, but the requiresClass() flag set.
This is not quite modeled this way yet and AnyObject still
exists, but the new abstraction is a step in the right
direction.
