Fix panic in getTokenAtPosition for JSDoc type assertions

[Copilot]

Fixes #1689

Problem

The language server would panic when performing go-to-definition on identifiers inside JSDoc type assertions. For example, placing the cursor on x in the following code and requesting a definition would crash:

function foo(x) {
    const s = /**@type {string}*/(x)  // Go-to-definition on x causes panic
}

The panic message was:

panic: did not expect KindParenthesizedExpression to have KindIdentifier in its trivia

Root Cause

JSDoc type assertions like /**@type {string}*/(x) create a ParenthesizedExpression with a reparsed AsExpression child. Reparsed nodes are marked with NodeFlagsReparsed and represent AST nodes created from JSDoc comments.

The visitNode function in getTokenAtPosition was unconditionally skipping all reparsed nodes to avoid returning positions within JSDoc comments. However, AsExpression and SatisfiesExpression are special cases where they can be marked as reparsed (from JSDoc) but their .Expression child should still be visited. When these were skipped, the function fell back to using a scanner, which then found the identifier x in what it thought was trivia, triggering the panic.

Solution

Modified visitNode to special-case AsExpression and SatisfiesExpression nodes. These are the only reparsed node types where their .Expression child should be navigable. The fix:

1. Allows AsExpression and SatisfiesExpression to be visited even when marked as reparsed
2. Sets an allowReparsed flag when navigating into these special nodes
3. Uses this flag to recursively allow visiting their reparsed children to reach identifiers

This targeted approach:

• Maintains the invariant that identifiers never appear in actual trivia (the panic is kept)
• Allows proper navigation through JSDoc type assertions and satisfies expressions
• Maintains strict reparsed node filtering for all other node types
• Preserves existing behavior for all other cases

Changes

• Modified internal/astnav/tokens.go to special-case AsExpression and SatisfiesExpression
• Added test cases covering JSDoc type assertions to prevent regression

The fix is precise and only affects the specific node types that need special handling while maintaining backward compatibility with all existing code.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Panic in getTokenAtPosition</issue_title>
<issue_description>## Stack trace

panic handling request textDocument/definition did not expect KindParenthesizedExpression to have KindIdentifier in its trivia goroutine 257 [running]:
runtime/debug.Stack()
	C:/Program Files/Go/src/runtime/debug/stack.go:26 +0x8e
github.com/microsoft/typescript-go/internal/lsp.(*Server).recover(0xc000168dc0, 0xc001b87860)
	c:/ts-go/internal/lsp/server.go:532 +0x53
panic({0x7ff6fa0c8080?, 0xc001aec730?})
	C:/Program Files/Go/src/runtime/panic.go:783 +0x136
github.com/microsoft/typescript-go/internal/astnav.getTokenAtPosition(0xc0008678c8, 0x35, 0x0, 0x7ff6fa3479b0)
	c:/ts-go/internal/astnav/tokens.go:176 +0x945
github.com/microsoft/typescript-go/internal/astnav.GetTouchingPropertyName(0xc0008678c8, 0x35)
	c:/ts-go/internal/astnav/tokens.go:12 +0x39
github.com/microsoft/typescript-go/internal/ls.(*LanguageService).ProvideDefinition(0xc0002a2a68, {0x7ff6fa3d93d0, 0xc001974140}, {0xc0002a8408, 0x17}, {0x1, 0x22})
	c:/ts-go/internal/ls/definition.go:17 +0x14f
github.com/microsoft/typescript-go/internal/lsp.(*Server).handleDefinition(0xc000168dc0, {0x7ff6fa3d93d0, 0xc001974140}, 0xc0002a2a68, 0xc001b87830)
	c:/ts-go/internal/lsp/server.go:735 +0xc9
github.com/microsoft/typescript-go/internal/lsp.registerLanguageServiceDocumentRequestHandler[...].func1({0x7ff6fa3d93d0, 0xc001974140}, 0xc001b87860)
	c:/ts-go/internal/lsp/server.go:518 +0x2a5
github.com/microsoft/typescript-go/internal/lsp.(*Server).handleRequestOrNotification(0xc000168dc0, {0x7ff6fa3d93d0, 0xc001974140}, 0xc001b87860)
	c:/ts-go/internal/lsp/server.go:424 +0xb9
github.com/microsoft/typescript-go/internal/lsp.(*Server).dispatchLoop.func1()
	c:/ts-go/internal/lsp/server.go:329 +0x65
created by github.com/microsoft/typescript-go/internal/lsp.(*Server).dispatchLoop in goroutine 23
	c:/ts-go/internal/lsp/server.go:349 +0x5c5

[Error - 1:22:40 PM] Request textDocument/definition failed.
  Message: InternalError: panic handling request textDocument/definition: did not expect KindParenthesizedExpression to have KindIdentifier in its trivia
  Code: -32603 

Steps to reproduce

Place the following code in a source file with a .js extension and go-to-definition on x in the type assertion.

function foo(x) {
    const s = /**@type {string}*/(x)  // Go-to-definition on x causes panic
}

</issue_description>

Comments on the Issue (you are @copilot in this section)

@ahejlsberg @andrewbranch I think you wrote the code for `getTokenAtPosition`, so assigning to you.

Fixes #1689

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[andrewbranch]

@copilot this isn’t a valid fix. JSDoc nodes are expected to be fully-formed subtrees, with their identifiers accounted for in the AST. I’m not sure what the issue is here, so what I want you to do is perform a thorough investigation of how this function works for other JSDoc nodes that don’t crash and compare with JSDoc type assertions. Track your investigation in copilot-notes.md and commit the file. If that leads you to discover the correct fix, go ahead and implement it; otherwise just revert what you’ve done here and submit your investigation notes. But you are not allowed to remove the panic—identifiers are never allowed in the trivia of nodes of any kind.

[Copilot]

@copilot this isn’t a valid fix. JSDoc nodes are expected to be fully-formed subtrees, with their identifiers accounted for in the AST. I’m not sure what the issue is here, so what I want you to d...

I've completed the investigation and implemented the proper fix in commit b59ddfc.

Root Cause: JSDoc type assertions create a ParenthesizedExpression with a reparsed AsExpression child (marked with NodeFlagsReparsed). The visitNode function was unconditionally skipping all reparsed nodes, so when the only path to an identifier was through this reparsed node, the scanner fallback was triggered and found the identifier, causing the panic.

Solution: Modified visitNode to track reparsed matches as a fallback (similar to how visitNodeList already works). When no non-reparsed node matches, we use the reparsed match. This allows navigation through JSDoc type assertions while maintaining the invariant that identifiers never appear in actual trivia.

Investigation details are documented in copilot-notes.md.

[andrewbranch]

@copilot You’re on the right track. Reparsed nodes are funny, because most of them indicate a cloned or synthesized node that exists outside the “real” tree and have no “real” position in the file. As far as I can tell, AsExpression and SatisfiesExpression are the only special cases where they are Reparsed, but their .Expression should be visited. Instead of making a general solution like this, try to just modify the existing reparsed node logic to special-case these node kinds.

[andrewbranch]

@copilot ^

[andrewbranch]

@copilot try again

[Copilot]

@copilot try again

Done. Refactored to specifically special-case AsExpression and SatisfiesExpression instead of a general fallback mechanism. The fix now:

1. Allows these two node types to be visited even when marked as reparsed
2. Sets an allowReparsed flag when navigating into them
3. Uses the flag to allow visiting their reparsed children (like identifiers)

This targeted approach maintains strict reparsed node filtering for all other cases. See commit 437f1cf.

[andrewbranch]

@copilot I think this is good. Just delete copilot-notes.md now.

[Copilot]

@copilot I think this is good. Just delete copilot-notes.md now.

Done. Removed copilot-notes.md in commit that will be pushed.

[Copilot]

Pull Request Overview

This PR fixes a panic in the getTokenAtPosition function when performing go-to-definition on identifiers inside JSDoc type assertions. The issue occurred because reparsed nodes from JSDoc comments were being unconditionally skipped, preventing proper navigation to identifiers within type assertions like /**@type {string}*/(x).

• Modified the visitNode function to allow special handling of AsExpression and SatisfiesExpression nodes
• Added an allowReparsed flag to enable recursive navigation through reparsed children of these special node types
• Added comprehensive test cases to prevent regression

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
internal/astnav/tokens.go	Implements the core fix by special-casing AsExpression and SatisfiesExpression nodes to allow navigation through their reparsed children
internal/astnav/tokens_test.go	Adds test cases covering JSDoc type assertions to verify the fix and prevent regression

[jakebailey]

Not sure if I can approve this, but let's try