Hacktoberfest 2026：維護者為十月標記出來的 issue，仍然開放、適合新手。 瀏覽 Hacktoberfest issue

TS7 LSP: documentHighlight returns nothing when the file path contains '@'

未關閉 適合新手
  • 哪裡不對？
#64,758 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

還沒有人認領這個 Issue。

評估

難度
2/5
預估耗時
1-3 小時
新手友好度
78/100
Issue 類型
缺陷
描述清晰度
描述清楚
活躍度
活躍
技術堆疊
go
領域
backend-api-design

研究方向

從 tsc/internal/ls/documenthighlights.go:30 開始，issue 在此指出原始 URI 字串比較；再檢查 tsc/internal/ls/lsconv/converters.go:315，了解 URI 編碼。使用提供的 TypeScript 檔案，在包含 @ 的路徑下重現，並比較編碼與未編碼 URI 的結果。完成標準是：對於兩種 URI 形式，文件醒目提示都回傳全部三個相符項目；issue 沒有指定測試檔案。

由索引模型根據 Issue 內容生成。

描述

🔎 Search Terms

documentHighlight, document highlight, URI encoding, percent-encoding, %40, @ in path, Neovim, LSP

🕗 Version & Regression Information
  • I was unable to test this on prior versions because this code is in the TS7 language server only. The old tsserver (through vtsls) does not have this problem.

I reproduced it with tsc --lsp 7.0.2. The same code is on main at ba1819f.

⏯ Playground Link

Not applicable. The problem is in the language server.

💻 Code

Put this file in a directory whose path contains @, for example /tmp/a@b/proj/x.ts, with an empty tsconfig.json next to it:

const foo = 1;
console.log(foo);
console.log(foo);
🙁 Actual behavior

textDocument/documentHighlight on foo (line 0, character 7) returns an empty array if the client sends the path with @ not encoded:

URI that the client sends Highlights
file:///tmp/a@b/proj/x.ts 0
file:///tmp/a%40b/proj/x.ts 3
file:///tmp/plain/proj/x.ts 3

Neovim sends the first form (vim.uri_from_fname("/tmp/a@b/x.ts") gives file:///tmp/a@b/x.ts). Thus, in Neovim, document highlights and features that use them (for example, jump to next reference) do not work in projects whose path contains @. Other requests, such as textDocument/references, work correctly on the same file.

🙂 Expected behavior

The server returns 3 highlights for all three URIs. The two a@b URIs identify the same file, and the server opens that file correctly from both forms.

Additional information about the issue

Cause. tsc/internal/ls/documenthighlights.go:30 filters the results with a raw string compare:

if mh.Uri == documentUri {
  • mh.Uri comes from lsconv.FileNameToDocumentURI, which encodes @ as %40 (tsc/internal/ls/lsconv/converters.go:315).
  • documentUri is the string that the client sent, without changes.

When the client does not encode @, the strings are different, and the filter removes all highlights. VS Code does not see this problem because vscode-uri also encodes @ as %40 (URI.file('/tmp/a@b/x.ts').toString() gives file:///tmp/a%40b/x.ts). Thus the two sides always agree.

Why this is a server problem. RFC 3986 permits @ in a path segment without encoding, so the client URI is valid. Also, the LSP specification (URI section) says:

Clients and servers should not assume that each other are encoding the same way (for example a client encoding colons in drive letters cannot assume server responses will have encoded colons).

Possible fix. Compare file names, not URI strings:

if mh.Uri.FileName() == documentUri.FileName() {

Another possible fix is to normalize documentUri one time before the loop. Other characters in extraEscapeReplacer (', (, ), *, +, ,, ;, =, !, $, &, and so on) probably cause the same problem with clients that do not encode them.

Related: #43261 had the same type of cause (a path-case mismatch caused document highlights to fail) in tsserver.

Environment

  • Neovim v0.12.0-dev, Linux (WSL2)
  • tsc --lsp 7.0.2
主要語言
Go
星號
111k
分支
16.4k
平均合併
1 天 16 小時
30 天內合併 PR
154

環境準備

在 Codespaces 中開啟

在瀏覽器裡用你自己的 GitHub 帳號啟動這個專案的開發容器。

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

microsoft/TypeScript 的其他 Issue

查看 microsoft/TypeScript 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。