You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[Sema] Fix crash when retrieving typeContextInfo for a partially bound generic type
In the following test case, we are crashing while building the generic signature of `someGenericFunc`, potentially invoked on `model` in line 11.
```swift
struct MyBinding<BindingOuter> {
func someGenericFunc<BindingInner>(x: BindingInner) {}
}
struct MyTextField<TextFieldOuter> {
init<TextFieldInner>(text: MyBinding<TextFieldInner>) {}
}
struct EncodedView {
func foo(model: MyBinding<String>) {
let _ = MyTextField<String>(text: model)
}
}
```
Because we know that `model` has type `MyBinding<TextFieldInner>`, we substitute the `BindingOuter` generic parameter by `TextFieldInner`. Thus, `someGenericFunc` has the signature `<TextFieldInner /* substitutes BindingOuter */, BindingInner>`. `TextFieldInner` and `BindingOuter` both have `depth = 1`, `index = 0`. Thus the verification in `GenericSignatureBuilder` is failing.
After discussion with Slava, the root issue appears to be that we shouldn’t be calling `subst` on a `GenericFunctionType` at all. Instead we should be using `substGenericArgs` which doesn’t attempt to rebuild a generic signature, but instead builds a non-generic function type.
--------------------------------------------------------------------------------
We slightly regress in code completion results by showing two `collidingGeneric` twice in the following case.
```swift
protocol P1 {
func collidingGeneric<T>(x: T)
}
protocol P2 {
func collidingGeneric<T>(x: T)
}
class C : P1, P2 {
#^COMPLETE^#
}
```
Previously, we were representing the type of `collidingGeneric` by a generic function type with generic param `T` that doesn’t have any restrictions. Since we are now using `substGenericArgs` instead of `subst`, we receive a non-generic function type that represents `T` as an archetype. And since that archetype is different for the two function signatures, we show the result twice in code completion.
One could also argue that showing the result twice is intended (or at least acceptable) behaviour since, the two protocol may name their generic params differently. E.g. in
```swift
protocol P1 {
func collidingGeneric<S>(x: S)
}
protocol P2 {
func collidingGeneric<T>(x: T)
}
class C : P1, P2 {
#^COMPLETE^#
}
```
we might be expected to show the following two results
```
func collidingGeneric<S>(x: S)
func collidingGeneric<T>(x: T)
```
Resolves rdar://76711477 [SR-14495]
0 commit comments