x/tools/gopls: adding a file to a package reports failed imports in the other package files #35949
Description
This is consistently reproducible with gopls+VSCode, on many versions of gopls up through db047d72 (go 1.13.4).
Example workflow:
I have a package with 4 files in it. 3 of the 4 files have various import statements, mixed between standard library and external packages. The 4th file only defines some constants and does not have any import statements. This package is within a multi-package repository, all packages share the same go.mod (~2 filesystem levels up the tree).
If I add a 5th file, the pre-existing 3 files with import statements in the same package all turn red immediately (in the VSCode file navigator). In those pre-existing 3 files, all of the import statements are now highlighted red with the error "could not import X (no package for import X)".
Adding a blank line to one of the files reporting an import error and re-saving the file does gofmt the file (to remove the blank line), but does not resolve the reported import errors.
Using VSCode's "Go: Restart Language Server" feature immediately updates the VSCode UI to no longer report broken imports.
Suspicions/Observations:
I noticed that the editor turns red immediately, while the new file is totally empty. I know that for go, an empty .go file results in a compilation error with go build:
[bhatfield server]% go build
can't load package: package github.com/digits/go-services/shared/server:
grpc.go:1:1: expected 'package', found 'EOF'
Unfortunately, adding package server to the empty file does not resolve the reported import errors in the other files.
Additionally, after restarting gopls in the workflow above, removing the package declaration from the new file and re-saving does not cause the other files to turn back red. However, as soon as I type package in the new/empty file, the other files turn red again.
Expectations:
I would expect a few different behaviors here:
- I would not expect an empty file to bring gopls into a state where all files in the package are reported as failed, as they are not, in fact, broken in any way.
- I would expect gopls to recover once the package declaration is corrected in the new file.
Impact:
The result of this error, which I have been living with (just regularly restarting gopls whenever it happens), means that I "feel like" gopls fights me when I try to refactor code by moving it between files, adding new files, etc.