Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン 初心者向け
  • 何か問題がありますか？
#64,758 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
78/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
go
領域
backend-api-design

調査の方向性

Issueで生のURI文字列の比較が指摘されている tsc/internal/ls/documenthighlights.go:30 から始め、URIエンコーディングを理解するために tsc/internal/ls/lsconv/converters.go:315 を調べてください。@ を含むパスにある提供済みのTypeScriptファイルを使って再現し、エンコード済みURIと未エンコードURIの結果を比較してください。どちらのURI形式でもドキュメントハイライトが3つすべての一致を返せば完了です。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日 19時間
マージ済み PR（30日）
193

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

microsoft/TypeScript のほかの issue

microsoft/TypeScript の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。