x/tools/gopls: recursive orphaned file reloading

[findleyr]

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

[gopherbot]

Change https://go.dev/cl/480197 mentions this issue: gopls/internal/lsp/cache: record unloadable files if loading completes

[gopherbot]

Change https://go.dev/cl/494401 mentions this issue: internal/lsp/cache: support loading multiple orphaned files