At starts jsdoc tag only after whitespace #42364
Merged
Conversation
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
Previously, inside a JSDoc tag's comment, @ would start a tag unless it was surrounded by backticks. However, looking at real code showed that only whitespace-preceded uses of @ were intended to start tags.
typescript-bot
added
Author: Team
For Milestone Bug
|
ping @andrewbranch @armanio123 |
andrewbranch
approved these changes
Jan 25, 2021
This was referenced Apr 8, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Previously, inside a JSDoc tag's comment, @ would start a tag unless it was surrounded by backticks. However, looking at real code showed that only whitespace-preceded uses of @ were intended to start tags.
Please suggest new test cases if you can think of them. I feel like there are not quite enough.
Discussion
Why add a boolean flag as context instead of more states?
Whitespace parsing applies to all four states and doesn't currently change states. Correctly representing was-previous-character-whitespace would require doubling the state space. For example, I would have split SavingComments into SavingCommentsNoWhitespace and SavingCommentsPreviousWhitespace. The code would have lots more transitions to worry about as well. I decided representing the decision as a single context boolean was simpler.
Why doesn't top-level parsing change?
Top-level parsing already behaves the way strict JSDoc parsers do -- anything preceding the first
@except (1) start of comment or (2) newline plus optional asterisk causes the@to be treated as a comment.Nobody's complained about this much!
Fixes #39371