Go in vscode on WSL2 "forgets" that globals exist

[napei]

What version of Go, VS Code & VS Code Go extension are you using?

• Run go version to get version of Go
  • go version go1.15.4 linux/amd64
• Run code -v or code-insiders -v to get version of VS Code or VS Code Insiders

  1.52.0-insider
  24b28f57be22fe3029cb17a1dd72d8d9c2d6468b
  x64
  

• Check your installed extensions to get the version of the VS Code Go extension
  • Version: 0.18.1
• Run go env to get the go development environment details
  go env output

  ``` GO111MODULE="" GOARCH="amd64" GOBIN="" GOCACHE="/home/napei/.cache/go-build" GOENV="/home/napei/.config/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOINSECURE="" GOMODCACHE="/home/napei/go/pkg/mod" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/home/napei/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/usr/local/go" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="/home/napei/vic/vicrewards-backend/go.mod" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build035989416=/tmp/go-build -gno-record-gcc-switches" ```

Share the Go related settings you have added/edited

Run Preferences: Open Settings (JSON) command to open your settings.json file.
Share all the settings with the go. or ["go"] or gopls prefixes.

{
  "go.languageServerFlags": ["-rpc.trace"],
  "go.useLanguageServer": true,
}

Describe the bug

When working in a nested folder structure, go sometimes "forgets" about globals declared in main. Everything compiles fine, and autocomplete is aware of globals but sometimes after a few seconds vscode will decide that anything declared in package main doesn't exist anymore. I use WSL2 for development due to needing to use Bazel, so I'm not sure if this happens on windows or not. This has been going on for quite a while, but I've sort of put up with it. I used the Go Nightly extension for a while which it also happened in.

My folder structure is kind of like this, using bazel as well. Everything works perfectly fine except for the IDE.

.
└── project/
    ├── api/
    │   └── store/
    │       ├── main.go
    │       ├── queue.go
    │       └── helpers.go
    ├── libs/
    │   ├── lib1/
    │   │   └── lib1.go
    │   └── lib2/
    │       └── lib2.go
    ├── go.mod
    └── go.sum

I can't share a proper repro as this is a company project. Ignoring the libs folder (just an example) variables in package main declared like var foo bool outside of functions are the culprit.

Reloading vscode fixes it for about 30 seconds until it comes back again.

This only happens with the file open in the editor, and even with every go file in the project open in the editor it still happens.

Screenshots or recordings

gopls logs: https://pastebin.com/raw/RKFPwmb0

For example in helpers.go the following occurs, even though rmq is defined in queue.go under the same package main

Some other things are defined in main.go

[hyangah]

@napei thanks for the issue report.

Did you open the project folder (where go.mod is located)?

I am not yet sure gopls works with bazel (golang/go#37205 and a couple of bazel related open issues in the golang/go repo). What's the relationship between vicrewadrds-backend/api/store/helpers.go and vicrewards-backend/bazel-vicrewards-backend/api/store/helpers.go?

@stamblerre can you please take a look at the trace? The trace looks different from usual gopls trace I am familiar with. I.e. no gopls version, go env results...

[napei]

Yes the project is opened in vscode where go.mod is, and there's only one go.mod for all the sub-projects inside.

Gopls seems to work most of the time with bazel from what I can see. This is an occasional issue that sometimes is triggered from a syntax error, but then it doesn't go away. I'm not sure though as I can't find a concrete way to repro this consistently. As far as bazel is concerned I don't think that should affect anything, as it just builds and links with extra steps; the source code is still there as normal. It just allows me to build a monorepo easier.

What's the relationship between vicrewadrds-backend/api/store/helpers.go and vicrewards-backend/bazel-vicrewards-backend/api/store/helpers.go?

From what I know, that's built output from bazel, but I'm not sure why it's in the trace as that's not seen to me in the IDE as it's a symlink in the root directory that is ignored specifically for bazel things. Go itself also ignores symlinks.

This is where bazel builds to I believe, and where some things get cached but I don't think it's supposed to be parsed. When I run go mod tidy in the root.

The trace looks different from usual gopls trace I am familiar with.

I copied it from the gopls (server) output in vscode and I've run another which appears to have things like version info in it for gopls and env output. Not sure why that wasn't in the other one. I removed one entry as it contained a printout of aproprietary source code. https://pastebin.com/raw/rZMFYt8e

EDIT: Just realied I should clarify, the log I put here does not experience the bug it just has env info and version info. When this happens again I'll try to get a log again.

I will note I am also using https://github.com/facebook/ent which means there's currently 47,268 lines of code in the ent directory, not sure if that impacts performance at all.

[stamblerre]

My guess is that the issue has to do with the lack of Bazel support in gopls. I can't identify the problem without a full log, but it sounds like there is some code getting regenerated, but gopls isn't getting the notifications about the file changes because the files are outside of the workspace, or something like that.

Until gopls has full support for Bazel, I'm afraid that you may have to deal with occasional errors like this one. If gopls gets stuck in a bad state, you can try using the Go: Restart Language Server command from the Command Palette (Ctrl+Shift+P). Otherwise, you can try turning gopls off ("go.useLanguageServer": false).

[napei]

@stamblerre is there a way I can tell gopls to ignore those symlink directories generated by bazel?

As far as I know, it should never know about or look at code inside those directories as it's a cache from bazel not the true source code I'm working on. Could the excludes in vscode filter down to gopls somehow?

[stamblerre]

gopls needs to be able to build the code in the workspace, and my understanding is that the generated code in the bazel-{bin,out} directories is probably necessary for gopls to do that. There have been a number of other Bazel users that encountered unexpected errors using gopls--the only correct solution would be golang/go#37205.

But in general, gopls doesn't support excluding certain directories.

[napei]

Interesting. I think my case is different as there is nothing at all in the symlink direcrories that gopls should need to know about i.e. I'm not doing any codegen outside of the workspace. It's literally just a line-for-line copy of the workspace code in there, but only ever kept up to date when bazel is run. But that's okay. I'll track that other issue for now.

[stamblerre]

If you can provide a complete log when you see the failure, I can try to understand the issue more specifically--I'm just making guesses based on my experience with Bazel.

[napei]

@stamblerre I managed to get a trace which contains errors for you.

https://pastebin.com/raw/hpanfixE

Apologies for the length, I left vscode open for a while and then went back to it and updated bazel dependency files which seems to have caused this.

It appears that running a bazel build to update those output files and restarting the language server helps to fix it, but that's not concrete.

[stamblerre]

It appears that running a bazel build to update those output files and restarting the language server helps to fix it, but that's not concrete.

This indicates to me that there are clearly some missing definitions that gopls needs to get updated about.

From the logs, it looks like gopls is treating each file as its own package and it can't get a correct mapping of which file belongs to which package. This is caused by the lack of Bazel support, and right now there is no workaround other than to disable the language server.

Going to close this in favor of golang/go#37205. Sorry about the inconvenience!