Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/tools/gopls: make it tolerant against non-file scheme DocumentURIs in requests #67225

Closed
hyangah opened this issue May 7, 2024 · 1 comment
Assignees
Labels
Documentation gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone

Comments

@hyangah
Copy link
Contributor

hyangah commented May 7, 2024

Gopls assumes source files are on disk and supports only 'file' scheme document URIs.
Even though some editors support virtual file systems, it expects clients to understand this requirement and send only 'file' scheme document URIs.

CL 543575 tightened the uri check and started to return errors for non-file scheme document URIs, even during the initialize request handling. Note error in initialize request handling is fatal. As more extensions and features in VS Code are implemented on virtual workspace folders, more users will observe this issue. Before cl/543575, gopls skipped non-file scheme folder URIs.

golang/vscode-go#3368: decompiler extension
golang/vscode-go#3375: gitlens extension

For most of document-oriented LSP requests, the VS Code Go plugin sends requests only for go-related files on disk, using the vscode LSP client's document filter settings. But, for folder URIs (initialize, didChangeWorkspaceFolders, ...), the plugin has to implement extra handling and that is currently lacking.

Unfortunately, it is tricky to filter non-file scheme folder URIs in the initialize request with the current LSP client. See microsoft/vscode-languageserver-node#1470. We can have temporary workaround using subclassing, but I found writing a meaningful test in vscode client side is complicated.

Since this limitation is gopls specific, I think it's better to make gopls tolerate non-file scheme document uris, rather than requiring clients to implement their own workarounds. And, I find this problem is easier to handle from gopls side :-). Writing convincing tests in gopls is much easier thank to the existing integration test framework.

To reproduce the problem ourselves, build and install the sample in-memory filesystem extension and open a workspace like

$ cat test.code-workspace
{
       "folders": [
               {
                       "name": "real",
                       "path": "."
               },
               {
                        "name": "virtual",
                        "uri": "memfs:///"
               },
       ]
}
@gopherbot gopherbot added Tools This label describes issues relating to any tools in the x/tools repository. gopls Issues related to the Go language server, gopls. labels May 7, 2024
@gopherbot gopherbot added this to the Unreleased milestone May 7, 2024
@gopherbot
Copy link
Contributor

Change https://go.dev/cl/583775 mentions this issue: gopls/internal/server: allow non-file scheme workspace folder URIs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Documentation gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Development

No branches or pull requests

3 participants