TypeScript: Services debug failure in presence of unclosed JSX fragment

Maybe related to #38317.

In a .tsx file:

let x = <></Foo>;

Hover over Foo, or click on Foo to get document highlights

[Trace  - 21:32:41.378] <semantic> Response received: quickinfo (12). Request took 2 ms. Success: false . Message: Error processing request. Debug Failure. Did not expect JsxClosingFragment to have an Identifier in its trivia
Error: Debug Failure. Did not expect JsxClosingFragment to have an Identifier in its trivia
    at addSyntheticNodes (c:\Users\drosen\.vscode-insiders\extensions\ms-vscode.vscode-typescript-next-4.4.20210512\node_modules\typescript\lib\tsserver.js:152168:30)
    at createChildren (c:\Users\drosen\.vscode-insiders\extensions\ms-vscode.vscode-typescript-next-4.4.20210512\node_modules\typescript\lib\tsserver.js:152157:9)
    at NodeObject.getChildren (c:\Users\drosen\.vscode-insiders\extensions\ms-vscode.vscode-typescript-next-4.4.20210512\node_modules\typescript\lib\tsserver.js:152101:56)
    at getTokenAtPositionWorker (c:\Users\drosen\.vscode-insiders\extensions\ms-vscode.vscode-typescript-next-4.4.20210512\node_modules\typescript\lib\tsserver.js:119030:43)
    at getTouchingToken (c:\Users\drosen\.vscode-insiders\extensions\ms-vscode.vscode-typescript-next-4.4.20210512\node_modules\typescript\lib\tsserver.js:119017:16)
    at Object.getTouchingPropertyName (c:\Users\drosen\.vscode-insiders\extensions\ms-vscode.vscode-typescript-next-4.4.20210512\node_modules\typescript\lib\tsserver.js:119009:16)
    at Proxy.getQuickInfoAtPosition (c:\Users\drosen\.vscode-insiders\extensions\ms-vscode.vscode-typescript-next-4.4.20210512\node_modules\typescript\lib\tsserver.js:153343:27)
    at IOSession.Session.getQuickInfoWorker (c:\Users\drosen\.vscode-insiders\extensions\ms-vscode.vscode-typescript-next-4.4.20210512\node_modules\typescript\lib\tsserver.js:164421:62)
    at Session.handlers.ts.Map.ts.getEntries._a.<computed> (c:\Users\drosen\.vscode-insiders\extensions\ms-vscode.vscode-typescript-next-4.4.20210512\node_modules\typescript\lib\tsserver.js:163331:61)
    at c:\Users\drosen\.vscode-insiders\extensions\ms-vscode.vscode-typescript-next-4.4.20210512\node_modules\typescript\lib\tsserver.js:165173:88
    at IOSession.Session.executeWithRequestId (c:\Users\drosen\.vscode-insiders\extensions\ms-vscode.vscode-typescript-next-4.4.20210512\node_modules\typescript\lib\tsserver.js:165164:28)
    at IOSession.Session.executeCommand (c:\Users\drosen\.vscode-insiders\extensions\ms-vscode.vscode-typescript-next-4.4.20210512\node_modules\typescript\lib\tsserver.js:165173:33)
    at IOSession.Session.onMessage (c:\Users\drosen\.vscode-insiders\extensions\ms-vscode.vscode-typescript-next-4.4.20210512\node_modules\typescript\lib\tsserver.js:165199:35)
    at Interface.<anonymous> (c:\Users\drosen\.vscode-insiders\extensions\ms-vscode.vscode-typescript-next-4.4.20210512\node_modules\typescript\lib\tsserver.js:167801:31)
    at Interface.emit (events.js:315:20)
    at Interface._onLine (readline.js:337:10)
    at Interface._normalWrite (readline.js:482:12)
    at Socket.ondata (readline.js:194:10)
    at Socket.emit (events.js:315:20)
    at addChunk (internal/streams/readable.js:309:12)
    at readableAddChunk (internal/streams/readable.js:284:9)
    at Socket.Readable.push (internal/streams/readable.js:223:10)
    at Pipe.onStreamRead (internal/stream_base_commons.js:188:23)

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 15 (15 by maintainers)

Most upvoted comments

Seems like no; I’m going to see if I can do what Andrew suggested by inventing things to recover instead and we’ll see, I guess.

jakebailey on Jan 20, 2022

so we’re not getting rid of the assertion then?

gabritto on Jan 20, 2022

I almost wonder what this debug assertion gets us.

Just to clarify this, it seems like the services code is trying to be clever to detect parser bugs, but effectively ends up re-encoding parser rules that may or may not be right without context (which this part of the code does not have).

In this case, I don’t think that the assertion is really correct; it’s only failing because it happens to be an identifier, but what if I stuck in 1234? No debug fail there, but that token is similarly stranded.

jakebailey on Jan 20, 2022