Attempt to reuse type parameter constraint nodes#58539
Attempt to reuse type parameter constraint nodes#58539weswigham merged 1 commit intomicrosoft:mainfrom
Conversation
| sym = resolveEntityName(leftmost, meaning, /*ignoreErrors*/ true, /*dontResolveAlias*/ true); | ||
| if ( | ||
| context.enclosingDeclaration && | ||
| (getNodeLinks(context.enclosingDeclaration).fakeScopeForSignatureDeclaration || !findAncestor(node, n => n === context.enclosingDeclaration)) && |
There was a problem hiding this comment.
A fourslash test was affected by the code change and made it clear this small change to #58516 was needed - checking that the entity name resolves within the enclosing context is just always required to ensure the name's actually available, not just when there's a fake scope.
| } | ||
|
|
||
| function visitExistingNodeTreeSymbolsWorker(node: Node): Node | undefined { | ||
| if (isJSDocTypeExpression(node)) { |
There was a problem hiding this comment.
The constraint type node for a type parameter declared in jsdoc is a JSDocTypeExpression which, as it turns out, is not actually a type node (according to isTypeNode, though the typesystem thinks it is - inconsistent much?), so it needs to get unwrapped; you also definitely don't want the {} from jsdoc copied into a .d.ts file in the first place! So the assertion triggering off the core of this change found this bug, which was nice.
Fixes #58511
We should probably also do defaults, but one thing at a time.