-
Notifications
You must be signed in to change notification settings - Fork 12.9k
Set startPos at EOF in jsdoc token scanner so node end positions for nodes terminated at EoF are right #24184
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
Changes from 6 commits
02f2081
525d091
de173ee
238cb59
f3afefe
880ab4a
8eabd89
f37086d
9318641
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -6,7 +6,7 @@ | |
"0": { | ||
"kind": "JSDocReturnTag", | ||
"pos": 8, | ||
"end": 16, | ||
"end": 15, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Odd to see all these end position shift sometimes +2, sometime +1, and sometimes -1. I assume you've done a spot check and the new positions are (hopefully more) correct in each case? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, the end just no longer includes the trailing whitespace at the end of the comment. |
||
"atToken": { | ||
"kind": "AtToken", | ||
"pos": 8, | ||
|
@@ -21,6 +21,6 @@ | |
}, | ||
"length": 1, | ||
"pos": 8, | ||
"end": 16 | ||
"end": 15 | ||
} | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -6,7 +6,7 @@ | |
"0": { | ||
"kind": "JSDocParameterTag", | ||
"pos": 8, | ||
"end": 62, | ||
"end": 64, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Per your other comment - why does this one get longer then? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Description scanning is including trailing whitespace now that the comment end token's start pos is fixed - nonfinal descriptions already had positions that included trailing whitespace like this, so.... 🤷♂️ TBH, I'd prefer if whitespace was nonsignificant in jsdoc parsing and only handled newlines - that's require some changes to how we handle descriptions, though (we'd need to scan them more like jsx text). |
||
"atToken": { | ||
"kind": "AtToken", | ||
"pos": 8, | ||
|
@@ -40,6 +40,6 @@ | |
}, | ||
"length": 1, | ||
"pos": 8, | ||
"end": 62 | ||
"end": 64 | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what prompts this change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a test expecting a single classification for the trailing whitespace and
*/
on a comment. With the parse change, the trailing whitespace isn't part of the tag name/type, but is part of the overall tag itself (here, tag) - so using the end from the tag itself was causing us to skip the whitespace in the output. By the way, can I add that whitespace parsing in jsdoc is really inconsistent? Where whitespace is consumed vs isn't is very... Arbitrary? I feel like only newlines should really be significant in jsdoc - do you know why were scanning whitespace into tokens at all?Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs to produce a comment text that looks like
That is, the second lines need to be indented two spaces, not 0 and not 17 and not 16.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But... why are we doing that indentation analysis with token scanning and not with string manipulation on the actual comment text? We already manipulate it to strip leading and trailing newlines.