You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This PR makes the parser parse @link tag and the language service offer symbols for entity names found at the beginning of those tags. Links are stored redundantly with comment text, so they're only used to provide (1) a span to an editor to format in some way (2) a symbol for the declaration of the link's target.
Future PRs
Parse # as type-space element access: Class#method. As well as, possibly, the normal TS syntax Class["method"], which doesn't currently parse either.
Open questions
I parse @see {@link ...} as a @see with no reference and a link in its comment text. I think that's OK.
I intentionally do not parse { @link X}, with a space separating { and @. I saw this only twice in my corpus, but @amcasey points out that it's easy to support with an additional skipWhitespace call. I originally skipped it because I had slightly less lookahead when the next token after { was @, but that made the code unreadable, so I dropped it.
Resolved questions
I introduced JSDocText and JSDocLink nodes into the AST, which better reflects the semantic relation of comments to their tags. It is more expensive, though, it means that jsdoc comment text is treated as a first-class member of the parse tree now.
The text of the link is still stored in the comment text, but that's now
kept in an object instead of just a string. Each link has the parse for
the entity reference, if there is one.
Needs lots more tests -- this just makes all the existing jsdoc tests
pass.
Thanks for the PR! It looks like you've changed the TSServer protocol in some way. Please ensure that any changes here don't break consumers of the current TSServer API. For some extra review, we'll ping @sheetalkamat, @amcasey, @mjbvz, @minestarks for you. Feel free to loop in other consumers/maintainers if necessary
Only thing I’m curious about is if there are some places where JSDoc can go, but otherwise entity names could not go, and therefore might expose a hole in getSymbolAtLocation.
@andrewbranch I indeed tried writing more tests and discovered a hole. I'll put up a commit that makes getSymbolAtLocation work with identifiers in links.
@jessetrinity any chance you could validate this doesn't break anything in VS? I don't think we'll just get @link tag support for free, but at least JSDoc tags and other stuff should continue to work (in plain .js / .html / .cshtml)
They are ambiguous; previously the parser preferred the type
interpretation, but will now look ahead and parse links instead when the
prefix is `{@link`.
* Revert "Revert "Editor support for link tag (#41877)" (#43302)"
This reverts commit 451d435.
* Fix parsing @link at end of comment
* Parse comments as string when no @link occurs
* fix lint
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
typescript-bot
added
the
For Uncommitted Bug
Fixes #35524 (80% solution)
This PR makes the parser parse
@linktag and the language service offer symbols for entity names found at the beginning of those tags. Links are stored redundantly with comment text, so they're only used to provide (1) a span to an editor to format in some way (2) a symbol for the declaration of the link's target.Future PRs
#as type-space element access:Class#method. As well as, possibly, the normal TS syntaxClass["method"], which doesn't currently parse either.Open questions
@see {@link ...}as a@seewith no reference and a link in its comment text. I think that's OK.{ @link X}, with a space separating{and@. I saw this only twice in my corpus, but @amcasey points out that it's easy to support with an additionalskipWhitespacecall. I originally skipped it because I had slightly less lookahead when the next token after{was@, but that made the code unreadable, so I dropped it.Resolved questions