fix subscript magic giving unresolved generic param type #23988
Merged
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.
fixes #19737
As in the diff,
semResolvedCall
sets the return type of a call to a proc to the type of the call. But in the case of the subscript magic, this type is the first generic param which is also supposed to be the type of the first argument, but this is invalid, the correct type is the element type eventually given bysemSubscript
. Some lines above also prevent the subscript magics from instantiating their params so this type ends up being an unresolved generic param.Since the type of the node is not
nil
,prepareOperand
doesn't try to type it again, and this unresolved generic param type ends up being the final type of the node. To prevent this, we just never set the type of the node if we encountered a subscript magic.Maybe we could also rename the generic parameters of the subscript magics to stuff like
DummyT
,DummyI
if we want this to be easier to debug in the future.