x/tools/gopls: Extension is having trouble with one package in a big project (the rest of the packages are fine)

[oakad]

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

[h9jiang]

I'm not expert in gopls typechecking but maybe Alan can share some thoughts on how to figure this out.

[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.

[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
}
]
}
}

[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.

[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.