Fix panic in completions within import attributes

[Copilot]

Plan to Fix Panic in Import Attributes Completions

• Understand the issue: The panic occurs when calling .Text() on ImportAttribute nodes in completions
• Add explicit lambda in completions code instead of modifying Node.Text()
• Create/update tests to validate the fix for all three test cases in the issue
• Run tests to verify the fix works
• Address review feedback - use GoToEachMarker for test iteration
• Run code review
• Run security checks with CodeQL
• Run formatter and linter

Summary

Fixed the panic in completions request within import attributes by updating the completions code to use an explicit lambda function instead of adding a case to Node.Text().

Changes made per review feedback:

• Reverted the KindImportAttribute case from Node.Text() in ast.go
• Updated completions.go line 1372 to use explicit lambda: core.Map(elements, func(el *ast.Node) string { return el.AsImportAttribute().Name().Text() })
• Added comment to test file indicating it can be deleted once similar tests are ported
• Updated test to use GoToEachMarker for cleaner iteration over all markers

All tests pass including:

• New test TestCompletionImportAttributes covering all three marker positions from the issue
• All existing completion tests
• Code review passed
• CodeQL security check passed

Security Summary

No security vulnerabilities were introduced or discovered during this change.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Panic in completions request within import attributes</issue_title>
<issue_description>```ts
import yadda1 from "yadda" with {/attr/}
import yadda2 from "yadda" with {attr/attrEnd1/: true}
import yadda3 from "yadda" with {attr: /attrValue/}

Test completions at each marker location

[error] panic handling requesttextDocument/completionUnhandled case in Node.Text: *ast.ImportAttribute goroutine 13298 [running]:
runtime/debug.Stack()
runtime/debug/stack.go:26 +0x5e
github.com/microsoft/typescript-go/internal/lsp.(*Server).recover(0xc0001e4008, 0xc021a75d70)
github.com/microsoft/typescript-go/internal/lsp/server.go:872 +0x58
panic({0xba49e0?, 0xc005d175c0?})
runtime/panic.go:783 +0x132
github.com/microsoft/typescript-go/internal/ast.(*Node).Text(0x4187f4?)
github.com/microsoft/typescript-go/internal/ast/ast.go:338 +0x42d
github.com/microsoft/typescript-go/internal/core.Map...
github.com/microsoft/typescript-go/internal/core/core.go:58
github.com/microsoft/typescript-go/internal/ls.(*LanguageService).getCompletionData.func12()
github.com/microsoft/typescript-go/internal/ls/completions.go:1372 +0x375
github.com/microsoft/typescript-go/internal/ls.(*LanguageService).getCompletionData.func18(...)
github.com/microsoft/typescript-go/internal/ls/completions.go:1689
github.com/microsoft/typescript-go/internal/ls.(*LanguageService).getCompletionData(0xc010337710, {0x107f7a8, 0xc010337620}, 0xc019937908, 0xc014ebf208, 0x24, 0xc00c8ce800)
github.com/microsoft/typescript-go/internal/ls/completions.go:1717 +0x1edf
github.com/microsoft/typescript-go/internal/ls.(*LanguageService).getCompletionsAtPosition(0xc010337710, {0x107f7a8, 0xc010337620}, 0xc014ebf208, 0x24, 0x0)
github.com/microsoft/typescript-go/internal/ls/completions.go:383 +0x2cf
github.com/microsoft/typescript-go/internal/ls.(*LanguageService).ProvideCompletion(0xc010337710, {0x107f7a8, 0xc010337620}, {0xc01d962e10?, 0xc010337620?}, {0x1d962e10?, 0xc0?}, 0xc001749830)
github.com/microsoft/typescript-go/internal/ls/completions.go:44 +0xc8
github.com/microsoft/typescript-go/internal/lsp.(*Server).handleCompletion(0xc000a08008?, {0x107f7a8?, 0xc010337620?}, 0xc01d962e10?, 0x40b92c?)
github.com/microsoft/typescript-go/internal/lsp/server.go:1208 +0x39
github.com/microsoft/typescript-go/internal/lsp.init.func1.registerLanguageServiceDocumentRequestHandler[...].16({0x107f7a8, 0xc010337620}, 0xc021a75d70)
github.com/microsoft/typescript-go/internal/lsp/server.go:621 +0x130
github.com/microsoft/typescript-go/internal/lsp.(*Server).handleRequestOrNotification(0xc0001e4008, {0x107f7e0?, 0xc00e11d950?}, 0xc021a75d70)
github.com/microsoft/typescript-go/internal/lsp/server.go:502 +0x14b
github.com/microsoft/typescript-go/internal/lsp.(*Server).dispatchLoop.func1()
github.com/microsoft/typescript-go/internal/lsp/server.go:405 +0x3a
created by github.com/microsoft/typescript-go/internal/lsp.(*Server).dispatchLoop in goroutine 10
github.com/microsoft/typescript-go/internal/lsp/server.go:425 +0x9ad

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

<comments>
</comments>

• Fixes Panic in completions request within import attributes #2286

---

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

[DanielRosenwasser]

@copilot go

[Copilot]

Pull request overview

This PR fixes a panic that occurred when requesting completions within import attributes by replacing a problematic direct call to Node.Text() with an explicit lambda function that properly extracts and converts the attribute name.

Key changes:

• Modified completions.go to use an explicit lambda that calls el.AsImportAttribute().Name().Text() instead of directly calling (*ast.Node).Text on ImportAttribute nodes
• Added comprehensive test coverage for all three problematic completion positions within import attributes

Reviewed changes

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

File	Description
internal/ls/completions.go	Replaced direct (*ast.Node).Text call with explicit lambda function that properly handles ImportAttribute nodes by extracting the name first before calling .Text()
internal/fourslash/tests/completionImportAttributes_test.go	Added new test covering all three marker positions from the original issue to ensure completions work within import attribute syntax

[gabritto]

What are the tests?

[DanielRosenwasser]

There's a few other completions tests like completionListForImportAttributes.ts that already work on import specifiers via baselineCompletions but I don't think we have VerifyBaselineCompletions yet.