JSDoc Instantiation Fixes #17553
JSDoc Instantiation Fixes #17553
Conversation
…te a builtin as a generic
src/compiler/checker.ts
Outdated
| @@ -18592,6 +18592,11 @@ namespace ts { | |||
| forEach(node.typeArguments, checkSourceElement); | |||
| if (produceDiagnostics) { | |||
| const symbol = getNodeLinks(node).resolvedSymbol; | |||
| if (!symbol) { | |||
| // There is no resolved symbol cached if the type resolved to a builtin via jsdoc type reference resolution, none of which are generic when they have no associated symbol | |||
There was a problem hiding this comment.
Wrap comment, jsdoc -> JSDoc
Give a specific example of what you mean by JSDoc type reference resolution (e.g. a snippet of when this can happen)
|
This same crash is also happening in a snippet that has See #17525 |
There was a problem hiding this comment.
@weswigham Can you verify whether this addresses #17525 as well?
|
@rbuckton It prevents it from throwing, but doesn't give it the correct behavior. We seem to be parsing |
|
I think we have three different repros on this, it'd be good to have all of them in the TC |
…if the type is a reference
|
I've also bundled a fix for #17377, which was actually another issue which manifested as a crash on the same line. We assumed that if there was no resolved symbol that we successfully instantiated the type, which is, of course, predicated on the type being instantiable; which in erroneous cases (such as the example), it is not. |
weswigham
changed the title
|
And now this fixes #17525, since they were all hidden behind a crash on the same line. |
| return; | ||
| } | ||
| let typeParameters = symbol.flags & SymbolFlags.TypeAlias && getSymbolLinks(symbol).typeParameters; | ||
| if (!typeParameters && getObjectFlags(type) & ObjectFlags.Reference) { |
There was a problem hiding this comment.
this check for objectFlags.Reference is new. What if it's false? Won't you still see a crash? When could it be false?
There was a problem hiding this comment.
Previously it was blindly assumed that if it wasn't a type alias, that it must be a type reference. This is not the case - it can just be erroneous (since we just mark a lookup error and return the type for the alternate meaning if the lookup fails); so we must check that we have a type reference before treating the type as such.
Fixes #17383. - We now assume that if a symbol does not exist, then we found a builtin, but tried to instantiate it, which does not work.
Fixes #17377. - We now assume that instantiation can fail (ie, if the type doesn't exist as a type) and only look up the type arguments if instantiation was a success.
Fixes #17525. - We now consider
*the potential start of a type.