any jsdoc tag after @callback causes debug assert

[06000208]

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.65.2 (system setup) and 1.66.0-insider
• OS Version: Windows 10 Pro 19044.1586

While writing javascript, intellisense and syntax highlighting seemingly kept freezing up or displaying incorrectly, which I found quite odd. It would go back to normal if I closed and reopened the file, but would happen again later.

Following that, I realized it happens whenever I edited a jsdoc comment in a specific way, and recorded gifs: Stable and Insiders, with extensions disabled and no extensions installed, respectively.

Though the above gifs were recorded on real code, with some minor trimming out code I've produced this gist which replicates it in the same manner as the gifs.

It seems to be caused by the @this {ListenerBlock} tag on line 11 in the gist, as it stops happening when that line isn't present. I also tried @this ListenerBlock in the same spot, which causes it to happen as well.

I don't know whether or not if it's valid jsdoc to use the @this tag in this way to document a function's this value, but it seems reasonable reading it's documentation. Though I now suspect this is invalid syntax, I've still reported the issue as I would personally expect invalid syntax inside comments to be disregarded/ignored, rather than cause problems.

Steps to Reproduce:

1. Open the file from the above gist, hover things to ensure intellisense is working
2. Backspace the line break on line 16 and enter new lines from line 15, as seen in the gifs
3. Intellisense is now either shifted over in a weird way, or doesn't display at all. Syntax highlighting has stopped working properly and appears to be shifted over, doesn't update when editing code.
4. Closing and reopening the file will cause it to return to normal, but it can be repeated.
5. Removing line 11 containing the @this {ListenerBlock} jsdoc tag causes it to stop happening.
6. Adding @this ListenerBlock back to the jsdoc comment documenting the callback also causes the syntax highlighting and intellisense to stop working properly.

[yume-chan]

Maybe because TypeScript doesn't support @this in @callback. I had never seen such usage either.

[Trace  - 10:16:28.535] <semantic> Response received: quickinfo (3107). Request took 2 ms. Success: false . Message: Error processing request. Debug Failure. Did not expect ClassDeclaration to have an Identifier in its trivia
Error: Debug Failure. Did not expect ClassDeclaration to have an Identifier in its trivia
    at addSyntheticNodes (/Users/simon/.vscode-insiders/extensions/ms-vscode.vscode-typescript-next-4.7.20220317/node_modules/typescript/lib/tsserver.js:161751:30)
    at processNodes (/Users/simon/.vscode-insiders/extensions/ms-vscode.vscode-typescript-next-4.7.20220317/node_modules/typescript/lib/tsserver.js:161729:13)
    at visitNodes (/Users/simon/.vscode-insiders/extensions/ms-vscode.vscode-typescript-next-4.7.20220317/node_modules/typescript/lib/tsserver.js:30151:24)
    at Object.forEachChild (/Users/simon/.vscode-insiders/extensions/ms-vscode.vscode-typescript-next-4.7.20220317/node_modules/typescript/lib/tsserver.js:30506:21)
    at NodeObject.forEachChild (/Users/simon/.vscode-insiders/extensions/ms-vscode.vscode-typescript-next-4.7.20220317/node_modules/typescript/lib/tsserver.js:161705:23)
    at createChildren (/Users/simon/.vscode-insiders/extensions/ms-vscode.vscode-typescript-next-4.7.20220317/node_modules/typescript/lib/tsserver.js:161739:14)
    at NodeObject.getChildren (/Users/simon/.vscode-insiders/extensions/ms-vscode.vscode-typescript-next-4.7.20220317/node_modules/typescript/lib/tsserver.js:161682:56)
    at _loop_1 (/Users/simon/.vscode-insiders/extensions/ms-vscode.vscode-typescript-next-4.7.20220317/node_modules/typescript/lib/tsserver.js:125779:36)
    at getTokenAtPositionWorker (/Users/simon/.vscode-insiders/extensions/ms-vscode.vscode-typescript-next-4.7.20220317/node_modules/typescript/lib/tsserver.js:125830:27)
    at getTouchingToken (/Users/simon/.vscode-insiders/extensions/ms-vscode.vscode-typescript-next-4.7.20220317/node_modules/typescript/lib/tsserver.js:125765:16)
    at Object.getTouchingPropertyName (/Users/simon/.vscode-insiders/extensions/ms-vscode.vscode-typescript-next-4.7.20220317/node_modules/typescript/lib/tsserver.js:125757:16)
    at Object.getQuickInfoAtPosition (/Users/simon/.vscode-insiders/extensions/ms-vscode.vscode-typescript-next-4.7.20220317/node_modules/typescript/lib/tsserver.js:162991:27)
    at IpcIOSession.Session.getQuickInfoWorker (/Users/simon/.vscode-insiders/extensions/ms-vscode.vscode-typescript-next-4.7.20220317/node_modules/typescript/lib/tsserver.js:174414:62)
    at Session.handlers.ts.Map.ts.getEntries._a.<computed> (/Users/simon/.vscode-insiders/extensions/ms-vscode.vscode-typescript-next-4.7.20220317/node_modules/typescript/lib/tsserver.js:173289:61)
    at /Users/simon/.vscode-insiders/extensions/ms-vscode.vscode-typescript-next-4.7.20220317/node_modules/typescript/lib/tsserver.js:175233:88
    at IpcIOSession.Session.executeWithRequestId (/Users/simon/.vscode-insiders/extensions/ms-vscode.vscode-typescript-next-4.7.20220317/node_modules/typescript/lib/tsserver.js:175224:28)
    at IpcIOSession.Session.executeCommand (/Users/simon/.vscode-insiders/extensions/ms-vscode.vscode-typescript-next-4.7.20220317/node_modules/typescript/lib/tsserver.js:175233:33)
    at IpcIOSession.Session.onMessage (/Users/simon/.vscode-insiders/extensions/ms-vscode.vscode-typescript-next-4.7.20220317/node_modules/typescript/lib/tsserver.js:175259:35)
    at process.<anonymous> (/Users/simon/.vscode-insiders/extensions/ms-vscode.vscode-typescript-next-4.7.20220317/node_modules/typescript/lib/tsserver.js:177894:31)
    at process.emit (node:events:390:28)
    at emit (node:internal/child_process:917:12)
    at processTicksAndRejections (node:internal/process/task_queues:84:21)

[sandersn]

During editing, before requesting quickinfo, I get

which is in IncrementalParser.updateSourceFile: Debug.assert(!incrementalSourceFile.hasBeenIncrementallyParsed)

Error: Debug Failure. False expression.
    at Object.updateSourceFile (/home/nathansa/ts/built/local/tsserver.js:38136:22)
    at Object.updateSourceFile (/home/nathansa/ts/built/local/tsserver.js:31121:47)
    at updateLanguageServiceSourceFile (/home/nathansa/ts/built/local/tsserver.js:163656:40)
    at SyntaxTreeCache.getCurrentSourceFile (/home/nathansa/ts/built/local/tsserver.js:163605:30)
    at Object.getNavigationTree (/home/nathansa/ts/built/local/tsserver.js:164326:71)
    at IpcIOSession.Session.getNavigationTree (/home/nathansa/ts/built/local/tsserver.js:176134:44)
    at Session.handlers.ts.Map.ts.getEntries._a.<computed> (/home/nathansa/ts/built/local/tsserver.js:174704:61)
    at /home/nathansa/ts/built/local/tsserver.js:176665:88
    at IpcIOSession.Session.executeWithRequestId (/home/nathansa/ts/built/local/tsserver.js:176656:28)
    at IpcIOSession.Session.executeCommand (/home/nathansa/ts/built/local/tsserver.js:176665:33)
    at IpcIOSession.Session.onMessage (/home/nathansa/ts/built/local/tsserver.js:176691:35)
    at process.<anonymous> (/home/nathansa/ts/built/local/tsserver.js:180021:31)
    at process.emit (node:events:390:28)
    at emit (node:internal/child_process:917:12)
    at processTicksAndRejections (node:internal/process/task_queues:84:21)

The failure during quickinfo is on the line in addSyntheticNodes:
if (token === SyntaxKind.Identifier)

[sandersn]

I haven't got a working test case, but I'm pretty sure the problem is the way that @callback behaves when it expects to parse a @return tag but finds something else (like @this).

Edit: At least, modifying parseCallbackTag to always treat a final tag as a return tag does avoid the crash.

[sandersn]

My test case fails with yet another assert in incremental parsing, in a pair of assertions that an element's new span is still contained by its parent's span. Now that I have something that's easy to debug, I should be able to come up with a fix.

     Error: Debug Failure. Expected 236 <= 235
      at adjustIntersectingElement (src/compiler/parser.ts:9030:23)
      at visitNode (src/compiler/parser.ts:9084:21)
      at visitNode (src/compiler/parser.ts:39:24)
      at forEachChild (src/compiler/parser.ts:585:21)
      at visitNode (src/compiler/parser.ts:9085:21)
      at visitArray (src/compiler/parser.ts:9119:25)
      at visitNodes (src/compiler/parser.ts:45:24)
      at forEachChild (src/compiler/parser.ts:536:24)
      at visitNode (src/compiler/parser.ts:9085:21)
      at visitNode (src/compiler/parser.ts:9088:29)
      at visitArray (src/compiler/parser.ts:9119:25)
      at visitNodes (src/compiler/parser.ts:45:24)
      at forEachChild (src/compiler/parser.ts:333:24)
      at visitNode (src/compiler/parser.ts:9085:21)
      at updateTokenPositionsAndMarkElements (src/compiler/parser.ts:9063:13)
      at Object.updateSourceFile (src/compiler/parser.ts:8828:13)
      at Object.updateSourceFile (src/compiler/parser.ts:758:49)
      at updateLanguageServiceSourceFile (src/services/services.ts:1163:39)
      at SyntaxTreeCache.getCurrentSourceFile (src/services/services.ts:1105:30)
      at Object.getFormattingEditsAfterKeystroke (src/services/services.ts:2049:48)
      at Function.proxy.<computed> [as getFormattingEditsAfterKeystroke] (src/harness/fourslashImpl.ts:399:66)
      at TestState.type (src/harness/fourslashImpl.ts:2197:56)
      at Edit.insertLines (src/harness/fourslashInterfaceImpl.ts:649:24)
      at Edit.insert (src/harness/fourslashInterfaceImpl.ts:641:18)
      at eval (jsThisCallbackNesting.js:45:6)

[sandersn]

My hypothesis was almost right. The problem is that every node after parseTagComments in parseCallbackTag is wrong because it advances the scanner one character too far. The same problem exists with parseTypedefTag as well, although I can't make it trip any asserts.

Parsing tag comments in the middle of the tag was always a bit hacky...