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: auto-completion not listing values from unimported packages #57939

Closed
dppascual opened this issue Jan 20, 2023 · 5 comments
Closed
Assignees
Labels
gopls Issues related to the Go language server, gopls. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone

Comments

@dppascual
Copy link

gopls version

golang.org/x/tools/gopls v0.11.0
    golang.org/x/tools/gopls@v0.11.0 h1:/nvKHdTtePQmrv9XN3gIUN9MOdUrKzO/dcqgbG6x8EY=

go env

GO111MODULE="on"
GOARCH="amd64"
GOBIN="/Users/dppascual/go/bin"
GOCACHE="/Users/dppascual/Library/Caches/go-build"
GOENV="/Users/dppascual/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/dppascual/go/pkg/mod"
GONOPROXY="*.bbva.com,*.igrupobbva"
GONOSUMDB="*.bbva.com,*.igrupobbva"
GOOS="darwin"
GOPATH="/Users/dppascual/go"
GOPRIVATE="*.bbva.com,*.igrupobbva"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.19"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/zg/tz2xtl3138bfl888yv2gc_600000gn/T/go-build3334315292=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Support for autocompletion of unimported packages was introduced in this ticket #31906, but it seems not working, not sure if this feature has been deprecated. When you create a new package and import a value from such package in another one placed in the same workspace, no member is shown in the completions suggestions pop up. Attached a video as an example:

completion_unimported_packages.mov

What did you expect to see?

A list of candidates from unimported packages.

What did you see instead?

No candidates at all until I manually import a package.

Editor and settings

Editor:

 nvim --version
NVIM v0.8.2
Build type: Release
LuaJIT 2.1.0-beta3
Compiled by brew@Monterey

Features: +acl +iconv +tui
See ":help feature-compile"

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/usr/local/Cellar/neovim/0.8.2/share/nvim"

Run :checkhealth for more info

Gopls settings:

  gopls = {
    gopls = {
      -- buildFlags = { "-tags=debug" },
      -- ["local"] = "github.com/sourcegraph/sourcegraph",
      analyses = {
        unusedparams = true,
      },
      staticcheck = true,
      experimentalPostfixCompletions = true,
      hints = {
        parameterNames = true,
        assignVariableTypes = true,
        constantValues = true,
        rangeVariableTypes = true,
        compositeLiteralTypes = true,
        compositeLiteralFields = true,
        functionTypeParameters = true,
      },
    },
  },
@gopherbot gopherbot added Tools This label describes issues relating to any tools in the x/tools repository. gopls Issues related to the Go language server, gopls. labels Jan 20, 2023
@gopherbot gopherbot added this to the Unreleased milestone Jan 20, 2023
@findleyr
Copy link
Contributor

findleyr commented Jan 26, 2023

Hi @dppascual, thank you for the report.

I think I know what this is. The unimported completion cache is built asynchronously in the background. If you added the v1 package recently, it will not show up in unimported completion.

If you restart gopls, you should get unimported completion for this package. Can you confirm?

Assuming that works, there is still a UX problem here: gopls knows that metadata has been invalidated, and so should invalidate the unimported completion cache eagerly.

@findleyr findleyr added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Jan 26, 2023
@dppascual
Copy link
Author

Hi @findleyr, thanks for your reply. I've just created a new package and after gopls is restarted, values from the recently created package are shown as candidates in the completions suggestions pop up.

On the other hand, if I start typing the name of any exported value (function, type, ...) with no package name explicitly indicated as a prefix; gopls only reports suggestions from imported packages or std library packages. It seems that if we want completion suggestions from unimported packages, gopls forces us to

  • Import explicitly the package or
  • Typing the name of the package followed by the name of the value.

Do you know if there is any configurable option to tell gopls that I want all packages from my current workspace to be taken into account when an autocompletion operation is performed?

@hyangah hyangah added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. and removed WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. labels Feb 1, 2023
@hyangah
Copy link
Contributor

hyangah commented Feb 1, 2023

Thanks for checking @dppascual

Assuming that works, there is still a UX problem here: gopls knows that metadata has been invalidated, and so should invalidate the unimported completion cache eagerly.

Agree that this is a UX bug - users shouldn't require to restart gopls. I marked this issue as NeedsInvestigation, but @findleyr, if you know how to fix this, please relabel it accordingly.

if I start typing the name of any exported value (function, type, ...) with no package name explicitly indicated as a prefix; ; gopls only reports suggestions from imported packages or std library packages ...

I think this needs to be tracked as a separate feature request.

I am not sure if gopls currently suggests std library package's exported functions or types before importing the package or prefixing with the package name. (I tried some and it was never successful). In theory, I see commonality with the workspace symbol search - as long as there is enough completion budget and no other candidates from imported packages is found.

@hyangah hyangah modified the milestones: Unreleased, gopls/later Feb 1, 2023
@findleyr findleyr modified the milestones: gopls/later, gopls/v0.12.0 Feb 2, 2023
@dppascual
Copy link
Author

I am not sure if gopls currently suggests std library package's exported functions or types before importing the package or prefixing with the package name. (I tried some and it was never successful). In theory, I see commonality with the workspace symbol search - as long as there is enough completion budget and no other candidates from imported packages is found.

Hi @hyangah, you are right, gopls does not suggest std library package's exported functions of types if the mentioned package is not imported or prefixed. I didn't realize the package from the std library was already imported when testing.

Thanks for checking @dppascual

I've been continue testing how gopls resolves values from packages recently created and found an unexpected behaviour during autocompletion procedure. Once gopls is restarted, packages recently created are taking account by gopls, but not always the server sends suggestions from such package, even when there is an exact-match.

I attach a video (compressed at 720p because at 1080p was too big) below where you can see better what I explain before. The type Unit from the package metrics is not always suggested by gopls.

unexported_package.mov

**Logs from gopls **

tail -f ~/.local/state/nvim/lsp.log | grep -C 3 'textDocument/completion' 

gopls.log

I think this needs to be tracked as a separate feature request.

Created a new issue to be tracked

@adonovan
Copy link
Member

Using VSCode with gopls v0.11.0, I confirm the problem reported in this issue. Specifically, I used a new subpackage of golang.org/x/tools and was unable to get struct field completions for fmt.Stringer or objectpath.Encoder. After upgrading to the latest gopls, both completions were offered. So this bug appears now to be fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
gopls Issues related to the Go language server, gopls. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Development

No branches or pull requests

5 participants