[5.5][Sema] Fix crash when retrieving typeContextInfo for a partially bound generic type #37086
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Cherry-picks #37034.
In the following test case, we are crashing while building the generic signature of
someGenericFunc
, potentially invoked onmodel
in line 11.Because we know that
model
has typeMyBinding<TextFieldInner>
, we substitute theBindingOuter
generic parameter byTextFieldInner
. Thus,someGenericFunc
has the signature<TextFieldInner /* substitutes BindingOuter */, BindingInner>
.TextFieldInner
andBindingOuter
both havedepth = 1
,index = 0
. Thus the verification inGenericSignatureBuilder
is failing.After discussion with Slava, the root issue appears to be that we shouldn’t be calling
subst
on aGenericFunctionType
at all. Instead we should be usingsubstGenericArgs
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.Previously, we were representing the type of
collidingGeneric
by a generic function type with generic paramT
that doesn’t have any restrictions. Since we are now usingsubstGenericArgs
instead ofsubst
, we receive a non-generic function type that representsT
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
we might be expected to show the following two results