Fix getTypeAtLocation for as const to not issue a diagnostic - #36741
Conversation
Sorry, something went wrong.
| function getTypeFromTypeReference(node: TypeReferenceType): Type { | ||
| const links = getNodeLinks(node); | ||
| if (!links.resolvedType) { | ||
| // handle LS queries on the `const` in `x as const` by resolving to the type of `x` |
There was a problem hiding this comment.
Instead of this shouldn't getTypeOfNode just check if it is const of as const expression should forward it to correct node instead?
Sorry, something went wrong.
There was a problem hiding this comment.
Ehhhhhh, it could, but I'd rather push the handling to here, to prevent us from ever attempting to resolve the const in as const as a real type reference, however we may get there in the future (plus, by doing it here the result is cached).
Sorry, something went wrong.
|
Is this related to #36490? I believe that PR was also about handling LS requests in larger spans (i.e. not just on identifiers). |
Sorry, something went wrong.
|
Not as far as I know - this is just about fixing us giving a bogus result (and adding a diagnostic) for the type of const in x as const when the LS requests the type at const. |
Sorry, something went wrong.
|
So it changes from wrong to right, rather than from nothing to something? Makes sense. |
Sorry, something went wrong.
Fixes #34913
checkAssertion in the normal codepath avoids calling into getTypeFromTypeNode on the const in as const expressions, however the checker getTypeAtLocation API may invoke it directly. Previously, this'd cause as resolution error, as we'd resolve an (entirely unused) variable named const and return its' type. With this change, we instead return the type of the expression associated with the const (which should be more useful to API consumers, I hope, and prevents any spurious errors from being added).