Auto-complete stopped working with VSCode

[kylepl]

Hi,

I recently enabled auto-complete with the editor support, which has been working great (thanks!) - but it suddenly stopped working.

I thought it might have been related to a gopls update, but reverting did not fix it.

I tried to do some debugging, and see errors like:

[Error - 11:30:47 AM] Request textDocument/inlayHint failed.
  Message: getting file for InlayHint: stat /home/kyle/.cache/bazel/_bazel_kyle/d86f6415f278f3ee1100d1200456d325/execroot/_main/bazel-out/k8-fastbuild/bin/external/rules_go+/stdlib_/gocache/72/72059092b7ebcd47e2a2a153e7d3c12cafc4d261d4f86a01ff6fb147d04fc2b4-d: no such file or directory
  Code: 0 

I wasn't sure if this was a new error that was causing something to stop or not. When I go to the gocache directory, it is just empty.

I've also noticed the "Inline Suggestions" in the bottom right of VS code just always says loading,

I do see some examples of textDocument/documentSymbol working.

Any further debugging suggestions welcome.

Thanks!

Kyle

[kylepl]

Further investigation - I have another development machine that does not have the problem (It uses gopls v0.18.1, the latest at the current time) - so it seems like that is not the cause.

I see no such errors like I see above, and if I go to external/rules_go+/stdlib_/gocache, it is populated with many things.

I also made the settings.json basically the same for both of the installations.

[kylepl]

I'm not familiar with the gocache, but it seems like only rules_go has it in external:

find bazel-bin/external/ -type d -name "gocache"

Output:
bazel-bin/external/rules_go+/stdlib_/gocache</pre>

[kylepl]

More investigation rambling:

I see the GoStdLib provider outputs the cache_dir. And that it can be a pre-compiled library from GoSDK or compiled separately (possibly one machine is doing one, one other other? Probably not?).

Inside of bazel-bin/external/rules_go+/stdlib_/stdlib.pkg.json (at least on the broken system), I see the references to the files that should be in go cache (like external/rules_go+/stdlib_/gocache/72/72059092b7ebcd47e2a2a153e7d3c12cafc4d261d4f86a01ff6fb147d04fc2b4-d).

When I look at the files on the system that is working, they are go source files - they seem to be for cgo. There are only ~17 references in that entire file into the go cache. I do see in the rules_go readme that you'll need a "A C/C++ toolchain (if using cgo). Bazel will attempt to configure the toolchain automatically." - and https://github.com/bazel-contrib/rules_go/wiki/Editor-setup mentions "CGo completion may not work".

Also, the driver tool seems to have special handling for stdlib: https://github.com/bazel-contrib/rules_go/blob/10b45b29fc0c52eefb68d9d0392f79dcd3d7cbc5/go/tools/gopackagesdriver/packageregistry.go#L26.

One thing I didn't mention, is the one that is working is PopOS, the one that is not working is Ubuntu - but might not be relevant.

[kylepl]

Well, I don't really understand why - but if I tell GOPACKAGESDRIVER to not use fastbuild (i.e. my default at least), and use -c opt or -c dbg, then it all works. On inspection, the gocache for those types is populated, so that seems to solve the problem. As to why it's different, I do not know.

Specfiically, within my vscode settings.json, I now have:

"go.toolsEnvVars": {
      "GOPACKAGESDRIVER": "${workspaceFolder}/my/path/to/gopackagedrivers.sh",
      "GOPACKAGESDRIVER_BAZEL_BUILD_FLAGS": "-c dbg"
    },

[rv32ima]

Is cgo enabled in your project? There have been some issues lately with how the gopackagesdriver invokes go list that I had to work around with https://github.com/bazel-contrib/rules_go/commit/cf3c3af34bd869b864f5f2b98e2f41c2b220d6c9

[kylepl]

I'm relatively new to go, and short answer is I'm not sure. I haven't personally written a library that used it, but not sure if the transitive set of what I'm using uses it.

Is there a setting I can enable in my bzlmod that disables it to see?

Also not obvious to me why this seems to only effect fastbuild for me (and in my, only on one machine..).

[rv32ima]

Yes! At $work we force everything to be pure / static with the following in our .bazelrc:

# Force CGO_DISABLED=0 and static linking for everything.
build --@rules_go//go/config:static
build --@rules_go//go/config:pure

[kylepl]

Ah, interesting. Found the details about it here: https://github.com/bazel-contrib/rules_go/blob/master/go/modes.rst#building-pure-go-binaries

I can try it out.

[rivernate]

I've been running into similar issues with Neovim:

[START][2025-03-12 10:55:48] LSP logging initiated [ERROR][2025-03-12 10:55:48] ...lsp/handlers.lua:562 '2025/03/12 10:55:48 warning: diagnostics failed: stat /home//.cache/bazel/bazel/c66920935c49587f64f0f764ab8abdcb/execroot/main/bazel-out/k8-fastbuild-ST-cfbb14c93590/bin/external/rules_go~/stdlib/gocache/10/10e58da8307029ee6254bf870f58547bcd8c633770314cd127d3a813d9625577-d: no such file or directory\n\tview_id="1"\n\tsnapshot=1\n\tdirectory=/home//Development/<repo_dir>//remove-old-lti-logs\n' [ERROR][2025-03-12 10:55:48] ...lsp/handlers.lua:562 '2025/03/12 10:55:48 warning: while diagnosing changed files: stat /home//.cache/bazel/bazel/c66920935c49587f64f0f764ab8abdcb/execroot/main/bazel-out/k8-fastbuild-ST-cfbb14c93590/bin/external/rules_go~/stdlib/gocache/10/10e58da8307029ee6254bf870f58547bcd8c633770314cd127d3a813d9625577-d: no such file or directory\n\tview_id="1"\n\tsnapshot=1\n\tdirectory=/home//Development/<repo_dir>//remove-old-lti-logs\n' [ERROR][2025-03-12 10:56:25] .../vim/lsp/buf.lua:63 0 "stat /home//.cache/bazel/bazel/c66920935c49587f64f0f764ab8abdcb/execroot/main/bazel-out/k8-fastbuild-ST-cfbb14c93590/bin/external/rules_go~/stdlib/gocache/10/10e58da8307029ee6254bf870f58547bcd8c633770314cd127d3a813d9625577-d: no such file or directory" [ERROR][2025-03-12 10:56:28] .../vim/lsp/buf.lua:63 0 "stat /home//.cache/bazel/bazel/c66920935c49587f64f0f764ab8abdcb/execroot/main/bazel-out/k8-fastbuild-ST-cfbb14c93590/bin/external/rules_go~/stdlib/gocache/10/10e58da8307029ee6254bf870f58547bcd8c633770314cd127d3a813d9625577-d: no such file or directory"

[kylepl]

Unfortunately, we do use some cgo, so I can not just disable it (circl is using it).

[gpanders]

I'm also running into this recently (I am not sure what's changed, as I've been using GOPACKAGESDRIVER for a while successfully). @kylepl's suggestion to set GOPACKAGESDRIVER_BAZEL_BUILD_FLAGS to -c dbg worked for me as well.

[gpanders]

Disabling CGO specifically for GOPACKAGESDRIVER also seems to work:

GOPACKAGESDRIVER_BAZEL_BUILD_FLAGS="--@io_bazel_rules_go//go/config:static --@io_bazel_rules_go//go/config:pure"

EDIT: Perhaps an even better option is setting the osusergo and netgo build tags to force the net and os/user packages to be built without cgo (which is what seems to be causing the problems, at least for me)

GOPACKAGESDRIVER_BAZEL_BUILD_FLAGS="--@io_bazel_rules_go//go/config:tags=osusergo,netgo"