Fix getTypeAtLocation for as const to not issue a diagnostic
#36741
Conversation
weswigham
requested review from
amcasey,
sandersn,
sheetalkamat and
RyanCavanaugh
| @@ -11336,6 +11336,11 @@ namespace ts { | |||
| 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?
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).
|
Is this related to #36490? I believe that PR was also about handling LS requests in larger spans (i.e. not just on identifiers). |
|
Not as far as I know - this is just about fixing us giving a bogus result (and adding a diagnostic) for the type of |
|
So it changes from wrong to right, rather than from nothing to something? Makes sense. |
Fixes #34913
checkAssertionin the normal codepath avoids calling intogetTypeFromTypeNodeon theconstinas constexpressions, however the checkergetTypeAtLocationAPI may invoke it directly. Previously, this'd cause as resolution error, as we'd resolve an (entirely unused) variable namedconstand return its' type. With this change, we instead return the type of the expression associated with theconst(which should be more useful to API consumers, I hope, and prevents any spurious errors from being added).