Closed
Description
While investigating #59184, I found what I think may be a long-standing bug in gopls that potentially explains many user reports (such as #54007).
- The logic to disambiguate command-line arguments packages creates at most one unique command-line-arguments package per load: https://github.com/golang/tools/blob/488ba869902f9944c4554b5628e2e86d04071e3e/gopls/internal/lsp/cache/load.go#L439
- The logic to reload orphaned files loads a go/packages query with many file= queries, and only marks files as unloadable if the load fails entirely: https://github.com/golang/tools/blob/488ba869902f9944c4554b5628e2e86d04071e3e/gopls/internal/lsp/cache/snapshot.go#L1591
Therefore, if orphaned file reloading tries to load N files, it will call go/packages once with N file= queries, which invokes go list
N times. The load will succeed, because it produces at least one package, but only one command-line-arguments package will be recorded. The next time orphaned file reloading occurs, it will retry with N-1 files.
I.e. orphaned reloading involves N^2 go list invocations...
CC @adonovan
Metadata
Metadata
Assignees
Labels
Type
Projects
Relationships
Development
No branches or pull requests
Activity
gopherbot commentedon Mar 29, 2023
Change https://go.dev/cl/480197 mentions this issue:
gopls/internal/lsp/cache: record unloadable files if loading completes
gopls/internal/lsp/cache: record unloadable files if loading completes
gopherbot commentedon May 11, 2023
Change https://go.dev/cl/494401 mentions this issue:
internal/lsp/cache: support loading multiple orphaned files
internal/lsp/cache: support loading multiple orphaned files