What version of Go, VS Code & VS Code Go extension are you using?
Version Information
* Run `go version` to get version of Go from _the VS Code integrated terminal_. - go version go1.24.3 darwin/arm64 * Run `gopls -v version` to get version of Gopls from _the VS Code integrated terminal_. - golang.org/x/tools/gopls v0.18.1 * Run `code -v` or `code-insiders -v` to get version of VS Code or VS Code Insiders. - 1.100.2 * Check your installed extensions to get the version of the VS Code Go extension - 0.46.1 * Run Ctrl+Shift+P (Cmd+Shift+P on Mac OS) > `Go: Locate Configured Go Tools` command. - go: /opt/homebrew/bin/go: go version go1.24.3 darwin/arm64 gopls: /Users/oakad/go/bin/gopls (version: v0.18.1 built with go: go1.24.1) gotests: /Users/oakad/go/bin/gotests (version: v1.6.0 built with go: go1.24.1) gomodifytags: /Users/oakad/go/bin/gomodifytags (version: v1.17.0 built with go: go1.24.1) impl: /Users/oakad/go/bin/impl (version: v1.4.0 built with go: go1.24.1) goplay: /Users/oakad/go/bin/goplay (version: v1.0.0 built with go: go1.24.1) dlv: /Users/oakad/go/bin/dlv (version: v1.24.1 built with go: go1.24.1) staticcheck: /Users/oakad/go/bin/staticcheck (version: v0.6.1 built with go: go1.24.1)
Share the Go related settings you have added/edited
"go.lintOnSave": "off", "[go]": { "editor.formatOnSave": false }, "go.toolsManagement.autoUpdate": true,
Describe the bug
I have multiple multi-package Go projects. They generally work fine (autocomplete, go to definition, the usual stuff).
However, one of the packages in the multi project workspace is consistently misbehaving. All the imports in the said package are highlighted with red line:
could not import bytes (missing metadata for import of "bytes")compiler[BrokenIImport] could not import time (missing metadata for import of "time")compiler[BrokenImport]
And so on.
There are only 3 source files (all smaller than 500 lines) in the said package and yet types defined in one of the files are highlighted with red lines in the other files ([UndeclaredName] errors). The extension tries to do things with those files but lags badly, it appears to be struggling.
Interestingly enough, if I hover a mouse over the package name in the package statement, only one file shows a correct package path. The rest 2 files confuse the correct package path with one of the imported dependencies.
All other packages and files in this and other projects work fine. It's just that one package, which compiles and works fine and otherwise looks like nothing special which is somehow causing an issue for the extension.
The issue manifests itself on multiple machines (MacOS and Linux). Deleting gopls cache, reinstalling tools is not helpful. There's nothing specific in the gopls log.
Steps to reproduce the behavior:
No idea. This one package in one project appears to be somehow bad, while everything else is fine.
I understand that there's not much to go by in this report, but may be somebody can give me some advice on how to diagnose the issue further.
Unfortunately, the package source is commercial and confidential in nature so I cannot share it.
Screenshots or recordings
Comment From: h9jiang
I'm not expert in gopls typechecking but maybe Alan can share some thoughts on how to figure this out.
Comment From: adonovan
Hi, sorry you're having trouble with gopls. I assume the project builds as normal. It may be hard for us to diagnose the problem without the ability to reproduce it. I wonder whether you are able to reveal even the package and import declarations of all the files in the problematic package? (Perhaps you could replace any important substrings with xxx or yyy without changing the structure.)
One possibility (if you are willing) is a screen-sharing chat session. But let's see what we can learn first.
Can you run "gopls stats" and see if there are any bug.Reports in the cache? It could be a recovered crash in the export data reader/writer.
Comment From: oakad
Nope, no bug reports extant:
$ ~/go/bin/gopls stats Initializing workspace... done (6.528587743s) Gathering bug reports... done (190.772071ms) Querying memstats... done (13.943822ms) Querying workspace stats... done (4.601561ms) Collecting directory info... done (7.065608ms) { "BugReports": [], "CacheDir": "/home/oakad/.cache/gopls/d582a9d8", "DirStats": { "Files": 6055, "TestdataFiles": 0, "GoFiles": 130, "ModFiles": 1, "Dirs": 397 }, "GOARCH": "amd64", "GOOS": "linux", "GOPACKAGESDRIVER": "", "GOPLSCACHE": "", "GoVersion": "go1.24.3", "GoplsVersion": "v0.18.1", "InitialWorkspaceLoadDuration": "6.528587743s", "MemStats": { "HeapAlloc": 176803560, "HeapInUse": 211369984, "TotalAlloc": 287712272 }, "WorkspaceStats": { "Files": { "Total": 5566, "Largest": 2381525, "Errs": 0 }, "Views": [ { "GoCommandVersion": "go1.24.3", "AllPackages": { "Packages": 962, "LargestPackage": 199, "CompiledGoFiles": 5568, "Modules": 98 }, "WorkspacePackages": { "Packages": 60, "LargestPackage": 10, "CompiledGoFiles": 137, "Modules": 1 }, "Diagnostics": 280 } ] } }
Comment From: oakad
I think the key problem is gopls, for some reason, not assigning the correct package identifier to 2 of the 3 source files. It is rather weird: why would it ignore the package directive, if "go build" works just fine?
The incorrect package path is actually one of the package dependencies, so at least it's not completely bogus.
Comment From: oakad
I have removed the ".../control" dependency (aliased in the package as "controlpb") and it fixed gopls immediately.
So clearly gopls has some issue with dependencies called "control" or "controlpb" for that matter. :-)
For a double check, I brought it back in, and gopls broke again.
Or, alternatively, it may be reacting to the file name being "control.go".
I could not repro this in another, new package, but it seems I can control the breakage in this one, broken package.
Comment From: adonovan
Hi, sorry for the delay. This is an interesting problem but hard to debug from the information available. I wonder whether you would be comfortable sharing more information over direct email (adonovan at google.com). It would be useful to know what go list -json says for both package dbconfig and package control. Alternative we could set up time for a video chat; my hours are roughly 9-5 ET.