Skip to content

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.

Sign up for GitHub

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
merged 9 commits into from
May 17, 2018
Merged

Set startPos at EOF in jsdoc token scanner so node end positions for nodes terminated at EoF are right #24184

Changes from 1 commit
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
02f2081
Set startPos at EOF in jsdoc token scanner to node end positions for …
weswigham May 16, 2018
525d091
More complete nonwhitespace token check, fix syntactica jsdoc classifier
weswigham May 17, 2018
de173ee
Use loop and no nested lookahead
weswigham May 17, 2018
238cb59
Do thigns unrelated to the bug in the test
weswigham May 17, 2018
f3afefe
Fix typo move return
weswigham May 17, 2018
880ab4a
Merge branch 'master' into fourslash-incremental-incrunundrum
weswigham May 17, 2018
8eabd89
Patch up typedef end pos
weswigham May 17, 2018
f37086d
Fix indentation, make end pos target more obvious
weswigham May 17, 2018
9318641
Merge branch 'master' into fourslash-incremental-incrunundrum
weswigham May 17, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 5 additions & 2 deletions src/compiler/parser.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6483,7 +6483,7 @@ namespace ts {

function isNextNonwhitespaceTokenEndOfFile(): boolean {
// We must use infinite lookahead, as there could be any number of newlines :(
while(true) {
while (true) {
nextJSDocToken();
if (token() === SyntaxKind.EndOfFileToken) {
return true;
Expand Down Expand Up @@ -6820,6 +6820,7 @@ namespace ts {
typedefTag.comment = parseTagComments(indent);

typedefTag.typeExpression = typeExpression;
let end: number;
Copy link
Member

Choose a reason for hiding this comment

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

does this quirk apply to callback tags too?

Copy link
Member

Choose a reason for hiding this comment

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

From our discussion: yes, and nested @param types too, but the problem isn't bad enough to fix right now. Instead we should fix it by fixing the jsdoc scanner to ignore whitespace (and change the way we generate tag descriptions).

if (!typeExpression || isObjectOrObjectArrayTypeReference(typeExpression.type)) {
let child: JSDocTypeTag | JSDocPropertyTag | false;
let jsdocTypeLiteral: JSDocTypeLiteral;
Expand Down Expand Up @@ -6848,10 +6849,12 @@ namespace ts {
typedefTag.typeExpression = childTypeTag && childTypeTag.typeExpression && !isObjectOrObjectArrayTypeReference(childTypeTag.typeExpression.type) ?
childTypeTag.typeExpression :
finishNode(jsdocTypeLiteral);
end = jsdocTypeLiteral.end;
Copy link
Member

Choose a reason for hiding this comment

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

is the indent on this statement correct? It looks weird to me.

}
}

return finishNode(typedefTag);
// Only include the characters between the name end and the next token if a comment was actually parsed out - otherwise it's just whitespace
return finishNode(typedefTag, end || typedefTag.comment !== undefined ? scanner.getStartPos() : (typedefTag.fullName || typedefTag.typeExpression || typedefTag.tagName).end);
}

function parseJSDocTypeNameWithNamespace(nested?: boolean) {
Expand Down