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

Jump to bottom

x/tools/gopls: completion fails for incomplete function literal parameter types #36479

Closed
seh opened this issue Jan 9, 2020 · 8 comments
Closed

x/tools/gopls: completion fails for incomplete function literal parameter types #36479

seh opened this issue Jan 9, 2020 · 8 comments
Labels
FrozenDueToAge gopls Issues related to the Go language server, gopls. help wanted 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. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Milestone
gopls/unplanned

Comments

@seh
Copy link
Contributor

seh commented Jan 9, 2020

What version of Go are you using (go version)?

go version go1.13.5 darwin/amd64

Does this issue reproduce with the latest release?

The version of gopls is fairly recent, as of this writing:

golang.org/x/tools/gopls 0.2.2
    golang.org/x/tools/gopls@v0.2.2 h1:ujGisyytgY1VGcmd66wIJ9+wVAfmodXj6daHM43HRXk=

What operating system and processor architecture are you using (go env)?

go env Output
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/seh/Library/Caches/go-build"
GOENV="/Users/seh/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/seh/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.13.5/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.13.5/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/seh/src/uber/kubernetes/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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/d5/r0rch5j95zjcjmh12gzb7lfc0000gn/T/go-build161365972=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Using an editor that inserts balanced delimiters—such as a closing parenthesis character after typing an opening parenthesis character—try to complete the function literal parameter type config at the cursor position, denoted by <> here:

type config struct {
}

type Option func(*config) error

func WithSomeOption(n int) Option {
	return func(c *co<>)
}

What did you expect to see?

gopls would respond to the editor's request for completion there, and supply the identifier config as a good option.

What did you see instead?

gopls stalls for a long while, but never produces any suggestions for completion.

If I delete the closing parenthesis after the co above, like this, gopls does offer completion suggestions:

func WithSomeOption(n int) Option {
	return func(c *co<>
}

Similarly, if I round out more of the function literal, and move the cursor back after "co," gopls will offer completion suggestions:

func WithSomeOption(n int) Option {
	return func(c *co<>) error {
	}
}

I can see that in various states of being incomplete, this is not yet valid code. However, given the propensity for editors to help us with balanced delimiter insertion, it would be nice to accommodate completion in this situation.
@gopherbot gopherbot added this to the Unreleased milestone Jan 9, 2020
@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 9, 2020
@stamblerre stamblerre modified the milestones: Unreleased, gopls v1.0 Jan 9, 2020
@stamblerre stamblerre removed this from the gopls/v0.5.0 milestone Jun 24, 2020
@stamblerre stamblerre added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jul 23, 2020
@stamblerre stamblerre added this to the gopls/unplanned milestone Oct 21, 2020
@KarthikNayak
Copy link
Contributor

KarthikNayak commented Jun 1, 2021 •
edited

This is no longer an issue, can you can confirm @seh?
CC @stamblerre

See the below screenshot

2021-06-01-184902_3840x1080_scrot

@stamblerre stamblerre added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Jun 1, 2021
@seh
Copy link
Contributor Author

seh commented Jun 1, 2021 •
edited

I find that if I start with just the opening parenthesis character like this,

return func(c *co<>

then the completion suggestions work as expected. However, if I allow my editor's insertion of balanced delimiters to proceed, such that I start with the closing parenthesis in place,

return func(c *co<>)

then completion fails when gopls reports the following error:

LSP :: Error from the Language Server: analysis ST1006 for package github.com/myorg/myrepo/path/to/package panicked: interface conversion: interface {} is nil, not *buildir.IR (Unknown error)

That looks like an error from staticcheck's "Poorly chosen receiver name" check.

[Time passes ...]

If I watch the output of gopls as I add and remove characters around the statement shown above, I see lots of failures out of statichceck for other checks like the following:

  • SA1017
  • SA1021
  • SA1023
  • SA1025
  • SA4012
  • SA4015
  • SA5005
  • SA9003
  • ST1005
  • ST1008

@stamblerre
Copy link
Contributor

The staticcheck errors are actually unrelated to the completion results. These are errors logged by gopls, but they shouldn't be user-facing. I believe that the Emacs LSP integration shows logged errors to the user, which is something that's likely been reported on their issue tracker (it shouldn't happen). Do you see anything in the logs from the completion request when you trigger the completion at that location?

@seh
Copy link
Contributor Author

seh commented Jun 1, 2021

In the *lsp-log* buffer, every time I type a character in the position shown above, I see a message like the following:

2021/06/01 16:46:22 imports fixes: AllImportsFixes: /Users/seh/src/path/to/file.go:57:9: expected expression
	file="/Users/seh/src/path/to/file.go"

I can't find any other output that seems related.

@KarthikNayak
Copy link
Contributor

then the completion suggestions work as expected. However, if I allow my editor's insertion of balanced delimiters to proceed, such that I start with the closing parenthesis in place,

return func(c *co<>)

Interesting, this is the scenario I tried to reproduce too. You can actually see the closing parenthesis in my image.

@seh
Copy link
Contributor Author

seh commented Jun 1, 2021

This could be due to a bunch of other Emacs packages just being too old. I'm using Aquamacs version 3.5, built atop Emacs version 25.3.50.1, which holds back from being able to update some packages that have declared that they don't work on anything older than Emacs 26.

If you can't reproduce the problem and wish to move on, I can accept that. Aquamacs may finally leap forward again in the coming months, and then all of this might just work itself out.

@stamblerre
Copy link
Contributor

If you can increase the verbosity of your logs, we can continue troubleshooting: https://github.com/golang/tools/blob/master/gopls/doc/troubleshooting.md#capture-logs. However, it is possible that there is some issue with caused by Emacs here. Also, can you please confirm that you are using the latest version of gopls (v0.6.11), or you can upgrade by running GO111MODULE=on go get golang.org/x/tools/gopls.

@seankhliao seankhliao added WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. and removed WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. labels Dec 26, 2022
@gopherbot
Copy link

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)

@golang golang locked and limited conversation to collaborators Jan 26, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge gopls Issues related to the Go language server, gopls. help wanted 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. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Milestone
gopls/unplanned
Development

No branches or pull requests
5 participants
@seh @KarthikNayak @stamblerre @gopherbot @seankhliao