Skip to content

Don't bind JSDoc type parameter in a TS file #16413

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
3 commits merged into from
Jun 9, 2017
Merged

Don't bind JSDoc type parameter in a TS file #16413

3 commits merged into from
Jun 9, 2017

Conversation

ghost
Copy link

@ghost ghost commented Jun 9, 2017

Fixes #16358
Now that we no longer bind @template tags, had to add some code to getSymbolAtLocation to get find-all-references working again.
Also discovered #16411.

@@ -5274,6 +5280,10 @@ namespace ts {

/* @internal */
export function isDeclaration(node: Node): node is NamedDeclaration {
if (node.kind === SyntaxKind.TypeParameter) {
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In a TypeScript file, a TypeParameter in JSDoc is just a comment, albeit one that is parsed.
In a JavaScript file, it's actually a declaration.

@mhegazy mhegazy requested a review from rbuckton June 9, 2017 19:45
@mhegazy
Copy link
Contributor

mhegazy commented Jun 9, 2017

@rbuckton can you please review this change.

return parameter && parameter.symbol;
}

if (entityName.parent!.kind === SyntaxKind.TypeParameter && entityName.parent!.parent!.kind === SyntaxKind.JSDocTemplateTag) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't compile with strictNullChecks (yet), and line 22553 is the only place in the whole file where we have a non-null expression. I'd rather we not use it here and remove the one above, as when the time comes and we do enable strictNullChecks, we could unintentionally miss a case because we added these too early.

const fullStart = state.options.findInComments || container.jsDoc !== undefined || forEach(search.symbol.declarations, d => d.kind === ts.SyntaxKind.JSDocTypedefTag);
for (const position of getPossibleSymbolReferencePositions(sourceFile, search.text, container, fullStart)) {
// Need to search in the full start of the node in case there is a reference inside JSDoc.
for (const position of getPossibleSymbolReferencePositions(sourceFile, search.text, container, /*fullStart*/ true)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't this have been true if container.jsDoc !== undefined, or are we opening this up to all comments of the container because we need to find it on a node where we don't currently parse JSDoc comments in the parser?

Copy link
Author

@ghost ghost Jun 9, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That was a bad test in the first place, because if you container is the SourceFile, container.jsDoc will always be undefined, but calling .getStart() on the SourceFile could still skip past jsdoc comments of its children.
We should probably never even bother with calling .getStart() in getPossibleSymbolReferencePositions anyway, because scanning to the start of a node is probably more expensive than just doing text search on the full range.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I made a PR for that: #16420

@ghost ghost merged commit 13b7d17 into master Jun 9, 2017
@ghost ghost deleted the jsdoc-template branch June 9, 2017 21:52
@microsoft microsoft locked and limited conversation to collaborators Jun 14, 2018
This pull request was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants