Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/tools/gopls: gopls not properly interpreting build.directoryFilters #71303

Open
djahandarie opened this issue Jan 17, 2025 · 3 comments
Open
Labels
gopls/metadata Issues related to metadata loading in gopls gopls Issues related to the Go language server, gopls. ToolProposal Issues describing a requested change to a Go tool or command-line program. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone

Comments

@djahandarie
Copy link

gopls version

golang.org/x/tools/gopls v0.17.0
    golang.org/x/tools/gopls@v0.17.0 h1:yiwvxZX6lAQzZtJyDhKbGUiCepoGOEVw7E/i31JUcLE=
    github.com/BurntSushi/toml@v1.4.1-0.20240526193622-a339e1f7089c h1:pxW6RcqyfI9/kWtOwnv/G+AzdKuy2ZrqINhenH4HyNs=
    github.com/google/go-cmp@v0.6.0 h1:ofyhxvXcZhMsU5ulbFiLKl/XBFqE1GSq7atu8tAmTRI=
    golang.org/x/exp/typeparams@v0.0.0-20231108232855-2478ac86f678 h1:1P7xPZEwZMoBoz0Yze5Nx2/4pxj6nw9ZqHWXqP0iRgQ=
    golang.org/x/mod@v0.22.0 h1:D4nJWe9zXqHOmWqj4VMOJhvzj7bEZg4wEYa759z1pH4=
    golang.org/x/sync@v0.9.0 h1:fEo0HyrW1GIgZdpbhCRO0PkJajUS5H9IFUztCgEo2jQ=
    golang.org/x/telemetry@v0.0.0-20241106142447-58a1122356f5 h1:TCDqnvbBsFapViksHcHySl/sW4+rTGNIAoJJesHRuMM=
    golang.org/x/text@v0.20.0 h1:gK/Kv2otX8gz+wn7Rmb3vT96ZwuoxnQlY+HlJVj7Qug=
    golang.org/x/tools@v0.27.1-0.20241211153006-a83c4ee29a47 h1:dFDhAo0DFSbmpMYZcvCfIQK9q/wH3fMI8V18Gbcnm9E=
    golang.org/x/vuln@v1.0.4 h1:SP0mPeg2PmGCu03V+61EcQiOjmpri2XijexKdzv8Z1I=
    honnef.co/go/tools@v0.5.1 h1:4bH5o3b5ZULQ4UrBmP+63W9r7qIkqJClEA9ko5YKx+I=
    mvdan.cc/gofumpt@v0.7.0 h1:bg91ttqXmi9y2xawvkuMXyvAA/1ZGJqYAEGjXuP0JXU=
    mvdan.cc/xurls/v2@v2.5.0 h1:lyBNOm8Wo71UknhUs4QTFUNNMyxy2JEIaKKo0RWOh+8=
go: go1.23.4

go env

GO111MODULE=''
GOARCH='arm64'
GOBIN=''
GOCACHE='/Users/darius/Library/Caches/go-build'
GOENV='/Users/darius/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/darius/go/pkg/mod'
GONOPROXY='github.com/[redacted]/*'
GONOSUMDB='github.com/[redacted]/*'
GOOS='darwin'
GOPATH='/Users/darius/go'
GOPRIVATE='github.com/[redacted]/*'
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/Users/darius/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.22.9.darwin-arm64'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/Users/darius/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.22.9.darwin-arm64/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.22.9'
GCCGO='gccgo'
AR='ar'
CC='clang'
CXX='clang++'
CGO_ENABLED='1'
GOMOD='/Users/darius/[redacted]/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 -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/zt/m98ktd916s16_d4xl9nq34v40000gp/T/go-build2505097657=/tmp/go-build -gno-record-gcc-switches -fno-common'

What did you do?

In VSCode, set

  "gopls": {
    [...]
    "build.directoryFilters": ["-", "+go", "-go/example"]
    [...]
  }

And then in go/example/example.go, have a function with an unused parameter

What did you see happen?

gopls still reports unusedparams error on example.go

What did you expect to see?

I expected to see no report of unusedparams errors in example.go.

Note, if +go is removed from the build.directoryFilters paths, it no longer shows, but of course this disables gopls entirely on my codebase which is not desirable.

Based on docs, build.directoryFilters seems intended to allow excluding a subdirectory like this:

Include only project_a, but not node_modules inside it: -, +project_a, -project_a/node_modules

Editor and settings

No response

Logs

No response

@djahandarie djahandarie added gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository. labels Jan 17, 2025
@gopherbot gopherbot added this to the Unreleased milestone Jan 17, 2025
@gabyhelp gabyhelp added the ToolProposal Issues describing a requested change to a Go tool or command-line program. label Jan 17, 2025
@adonovan adonovan added the gopls/metadata Issues related to metadata loading in gopls label Jan 17, 2025
@adonovan
Copy link
Member

@samthanawalla is working on #42965, which is a standard mechanism for go.mod files to ignore certain trees (for example, containing files in languages other than Go). Once that mechanism is implemented, gopls should take advantage of it.

@peterldowns
Copy link

peterldowns commented Feb 3, 2025

+1, it's really annoying that analyzers don't allow excluding results from specific directories. I also encounter this when using vendored dependencies in vendor/ — no way for me to make any changes to them, but they show up in the list of problems that the LSP provides.

In the vendored dependencies case, I'd actually like to keep the code in the general LSP build but exclude it from the analyses. So I'm not sure that #42965 would be the correct solution here. My goal would be to still jump-to-definition into the vendored dependencies, find references, etc — but just not run the analyzers there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
gopls/metadata Issues related to metadata loading in gopls gopls Issues related to the Go language server, gopls. ToolProposal Issues describing a requested change to a Go tool or command-line program. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Development

No branches or pull requests

6 participants