The non-metatype case was never supported. The same should hold for the
existential metatype case, which used to miscompile and now crashes
because the invariant reference is deemed OK but the erasure expectedly
fails to handle it:
```swift
class C<T> {}
protocol P {
associatedtype A
func f() -> any P & C<A>
func fMeta() -> any (P & C<A>).Type
}
do {
let p: any P
let _ = p.f() // error
let _ = p.fMeta() // crash
}
```
Only preserve primary associated types during type erasure if the
generic context does not contain outer generic prameters.
i.e.
Given `func foo { ... any P <Int> ... }` getNonDependentUpperBounds()
should produce any P<Int>
However, given `func foo<T> { ... any P<T> ... }` getNonDependentUpperBounds()
should produce any P
Fixes rdar://110262754
Opened existentials should be erased to the dependent upper bound
if the dependent member can be reduced to a concrete type. This
allows the generic signature to support parameterized protocol types
and bound generic class types by producing a more specific constraint
instead of just a plain protocol or class.
If erased result is passed as an argument to a call that requires
implicit opening, the fix-it should use parens to avoid suppressing
the opening at that argument position.
Accessing members on the protocol could result in existential opening and subsequence
result erasure, which requires explicit coercion if there is any loss of generic requirements.
For types like `<Base>.B.C` we need to check that neither
`B` nor `C` have any additional requirements because they
cannot be expressed in the existential type.
To ensure that we do not accept code that would require an existential call argument
to be evaluated prior to the call, don't open existential call
arguments if the generic parameter that would capture the opened
existential type is used in any prior parameter.
Note that code generation currently moves the opening of the
existential call argument outside of the call, which is a compiler bug.
This change ensures that we don't accept code would *require* this
out-of-order evaluation and adds a test so we know when we fix this.
When we open an existential argument in a call to a generic function,
type-erase contravariant uses of that opened existential in subsequent
parameters. This primarily impacts closure parameters, where we want
the closure to be provided with an existential parameter type rather
than permit the parameter to have opened existential type. This
prevents the opened existential type from being directly exposed in
the type system.
Note that we do not need to perform this erasure when the argument is
a reference to a generic function, because there it is suitable to
infer that the generic arguments are the opened archetypes. This
subsumes the use case for `_openExistential`.
This reverts commit 6e7fff7e65283ae9b25116fa6b75ba92fd2f2a58. The
asymmetry between opening for optional parameters and optional
arguments is surprising enough that we're currently opting not to
allow them.
Ensure that we only open existentials in an argument when the corresponding
parameter's type is a generic parameter that is only used in covariant
positions, because either invariant or contravariant uses mean that we
won't be able to type-erase other uses of that parameter. This mirrors
the requirement placed when opening existentials as a member of protocol
type.
An opaque type is only invariant with respect to the existential Self
when the constraints on the opaque type involve Self. Such constraints
are not expressible in the type-erased value, so treat them as
invariant. This loosens the restriction on using members of protocol
type that return an opaque type, such that (e.g.) the following is
still well-formed:
protocol P { }
protocol Q { }
extension P {
func getQ() -> some Q { ... }
}
func test(p: any P) {
let q = p.getQ() // formerly an error, now returns an "any Q"
}
However, this does not permit uses of members such as:
extension P {
func getCollection() -> some Collection<Self> { ... } // error
}
because the type system cannot express the corresponding existential
type `any Collection<Self>`.
When calling a generic function with an argument of existential type,
implicitly "open" the existential type into a concrete archetype, which
can then be bound to the generic type. This extends the implicit
opening that is performed when accessing a member of an existential
type from the "self" parameter to all parameters. For example:
func unsafeFirst<C: Collection>(_ c: C) -> C.Element { c.first! }
func g(c: any Collection) {
unsafeFirst(c) // currently an error
// with this change, succeeds and produces an 'Any'
}
This avoids many common sources of errors of the form
protocol 'P' as a type cannot conform to the protocol itself
which come from calling generic functions with an existential, and
allows another way "out" if one has an existention and needs to treat
it generically.
This feature is behind a frontend flag
`-enable-experimental-opened-existential-types`.
