Closed mattwelke closed 8 months ago
Adding a note:
Twice now in the past few minutes, it happened IFF I made a change to a struct name and then saved the file. The first time I changed the name, I did it via Rename Symbol. The second time I changed the name, I did so manually.
staticcheck
is the default linter that runs separate from gopls. https://github.com/golang/vscode-go/wiki/features#lint-errors
When and with what scope linters run is controlled by the go.lintOnSave
setting. I don't know how staticcheck ended up with the broken state. When you fall into such state, can you try "Go: Lint Current Package" (or current workspace) command and see if this misleading diagnostics go away?
Alternatively, you can turn off go.lintOnSave
and configure gopls to run staticcheck
instead.
@hyangah It's been good for a few days now. But I'll keep an eye on things and come back to this to run that command to see if the misleading lint results go away. Thanks!
When you fall into such state, can you try "Go: Lint Current Package" (or current workspace) command and see if this misleading diagnostics go away?
Ran into the broken state today. Was able to reproduce it by reloading the window, then adding a whitespace character that would be automatically removed upon save, and then saving again. I got the "x is unused" false positive problems again.
Ran Go: Lint Current Package
and the misleading diagnostics did not go away. I looked in the OUTPUT tab to see if any of the dropdown items (like Go
) has interesting info. I didn't see anything.
Thanks. If Go: Lint Current Package
doesn't clear that, can you manually run staticcheck and see if staticcheck still produces it?
cd <package_dir>
staticcheck .
Now gopls is on and the only supported way to get diagnostics, I think it's time to consider to switch go.lintOnSave
default to 'off'. cc @golang/tools-team
Actually, let me try again to witness this happening and carefully analyze my code base when it does. I think the issue today may have started when I did legitimately have unused code. And I think that what happens which makes the diagnostics confusing to me is that it's transitive, perhaps when it isn't meant to be. It ends up telling me that functions are unused when the functions that call them are themselves unused. So I ended up with a full "PROBLEMS" tab because of a deep chain of calls. Sorry for the hassle. I think with this kind of issue, I need to be careful when I'm reporting it.
Issue hasn't recurred. Going to conclude for now that this was a false positive and that I did indeed have unused code (through some transitive relationship between parts of my code).
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_. - go1.21.3 linux/amd64` * Run `gopls -v version` to get version of Gopls from _the VS Code integrated terminal_. - `v0.14.2` * Run `code -v` or `code-insiders -v` to get version of VS Code or VS Code Insiders. - `1.84.2` * Check your installed extensions to get the version of the VS Code Go extension - `v0.40.0` * Run Ctrl+Shift+P (Cmd+Shift+P on Mac OS) > `Go: Locate Configured Go Tools` command. ``` Checking configured tools.... GOBIN: undefined toolsGopath: gopath: /home/matt/go GOROOT: /usr/local/go PATH: /home/matt/.vscode-server/bin/1a5daa3a0231a0fbba4f14db7ec463cf99d7768e/bin/remote-cli:/home/matt/.local/bin:/home/matt/.rbenv/shims:/home/matt/.rbenv/bin:/home/matt/go/bin:/home/matt/.local/bin:/home/matt/.pyenv/shims:/home/matt/.pyenv/bin:/home/matt/.sdkman/candidates/visualvm/current/bin:/home/matt/.sdkman/candidates/micronaut/current/bin:/home/matt/.sdkman/candidates/maven/current/bin:/home/matt/.sdkman/candidates/java/current/bin:/home/matt/.sdkman/candidates/gradle/current/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/wsl/lib:/mnt/c/Program Files (x86)/NVIDIA Corporation/PhysX/Common:/mnt/c/Windows/system32:/mnt/c/Windows:/mnt/c/Windows/System32/Wbem:/mnt/c/Windows/System32/WindowsPowerShell/v1.0/:/mnt/c/Windows/System32/OpenSSH/:/mnt/c/Program Files/Git/cmd:/mnt/c/WINDOWS/system32:/mnt/c/WINDOWS:/mnt/c/WINDOWS/System32/Wbem:/mnt/c/WINDOWS/System32/WindowsPowerShell/v1.0/:/mnt/c/WINDOWS/System32/OpenSSH/:/mnt/c/Program Files/NVIDIA Corporation/NVIDIA NvDLISR:/mnt/c/Program Files/Docker/Docker/resources/bin:/mnt/c/Ruby31-x64/bin:/mnt/c/Users/mattw/AppData/Local/Microsoft/WindowsApps:/mnt/c/Users/mattw/AppData/Local/Programs/Microsoft VS Code/bin:/mnt/c/Users/mattw/AppData/Local/JetBrains/Toolbox/scripts:/mnt/c/Users/mattw/AppData/Local/Microsoft/WindowsApps:/snap/bin:/home/matt/.dotnet/tools:/usr/local/go/bin:/home/matt/n/bin:/home/matt/.rvm/bin go: /usr/local/go/bin/go: go version go1.21.3 linux/amd64 gopls: /home/matt/go/bin/gopls (version: v0.14.2 built with go: go1.21.3) gotests: /home/matt/go/bin/gotests (version: v1.6.0 built with go: go1.21.3) gomodifytags: /home/matt/go/bin/gomodifytags (version: v1.16.0 built with go: go1.21.3) impl: /home/matt/go/bin/impl (version: v1.1.0 built with go: go1.21.3) goplay: /home/matt/go/bin/goplay (version: v1.0.0 built with go: go1.21.3) dlv: /home/matt/go/bin/dlv (version: v1.21.1 built with go: go1.21.3) staticcheck: /home/matt/go/bin/staticcheck (version: v0.4.6 built with go: go1.21.3) go env Workspace Folder (new-rbac-rule): /home/matt/new-rbac-rule GO111MODULE='' GOARCH='amd64' GOBIN='' GOCACHE='/home/matt/.cache/go-build' GOENV='/home/matt/.config/go/env' GOEXE='' GOEXPERIMENT='' GOFLAGS='' GOHOSTARCH='amd64' GOHOSTOS='linux' GOINSECURE='' GOMODCACHE='/home/matt/go/pkg/mod' GONOPROXY='' GONOSUMDB='' GOOS='linux' GOPATH='/home/matt/go' GOPRIVATE='' GOPROXY='https://proxy.golang.org,direct' GOROOT='/usr/local/go' GOSUMDB='sum.golang.org' GOTMPDIR='' GOTOOLCHAIN='auto' GOTOOLDIR='/usr/local/go/pkg/tool/linux_amd64' GOVCS='' GOVERSION='go1.21.3' GCCGO='gccgo' GOAMD64='v1' AR='ar' CC='gcc' CXX='g++' CGO_ENABLED='1' GOMOD='/home/matt/new-rbac-rule/go.mod' GOWORK='' CGO_CFLAGS='-O2 -g' CGO_CPPFLAGS='' CGO_CXXFLAGS='-O2 -g' CGO_FFLAGS='-O2 -g' CGO_LDFLAGS='-O2 -g' PKG_CONFIG='pkg-config' GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build1867504942=/tmp/go-build -gno-record-gcc-switches' ```
Share the Go related settings you have added/edited
n/a
Describe the bug
Observed:
After coding for sometime, and doing things like renaming (using the Rename Symbol right click menu option) structs or functions, cutting and pasting code, copying and pasting code, and renaming files, VS Code starts to tell me that structs and functions in my code are unused, even though they are. I don't recall exactly which action I performed that triggered it, that's why I listed the kinds of things I'm doing in general when it does happen.
Not only do I know my code is used because I just wrote it and I remembered that I used it, I can see that it's used by using the find references tool:
Saving the file does not fix the issue.
However, I can fix this issue by running
Developer: Reload Window
from the command palette.Expected:
VS Code continues to be able to keep track of which Go code I write is used and unused, no matter what I do while I'm coding. And that it does so without me needing to run
Developer: Reload Window
.Steps to reproduce the behavior:
Unknown. So far, I've had it happen multiple times over the past week or so, generally happening when I'm doing the things I described above.
Some logs I think might be useful
OUTPUT tab - Go:
OUTPUT tab - gopls:
OUTPUT tab - Extension Host (Remote):
Notes
I am reporting the issue here instead of for gopls because the tool tip mentioned what sounds like a particular Go tool (staticcheck) instead of gopls. Please let me know if this is actually related to gopls and not the VS Code extension.