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: deep completions for types in structs show non-type items #34412

Closed
zikaeroh opened this issue Sep 19, 2019 · 4 comments
Closed

x/tools/gopls: deep completions for types in structs show non-type items #34412

zikaeroh opened this issue Sep 19, 2019 · 4 comments
Labels
FrozenDueToAge gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone
Unreleased

Comments

@zikaeroh
Copy link
Contributor

What did you do?

Typed string in a struct definition, to define a field.

What did you expect to see?

A list of completions of types as I typed string, correct for the context I'm typing in.

What did you see instead?

image

The first two are normal completions, and make sense. The last three are deep completions, but only the first is actually a type.

Build info

golang.org/x/tools/gopls v0.1.6
    golang.org/x/tools/gopls@v0.1.8-0.20190919162728-f68e2b6f23fc h1:3vwhnwNtccN9z6m7XLN6gNYSTWI05rXHP4xxpMBeqe8=
    golang.org/x/sync@v0.0.0-20190423024810-112230192c58 h1:8gQV6CLnAEikrhgkHFbMAEhagSSnXWGV915qUMm9mrU=
    golang.org/x/tools@v0.0.0-20190919162728-f68e2b6f23fc h1:1YT4tWqCW/31CBxEx+em+l1xN+VLaear67KgTPgqVy8=
    golang.org/x/xerrors@v0.0.0-20190717185122-a985d3407aa7 h1:9zdDQZ7Thm29KFXgAX/+yaf3eVbP7djjWp/dXAppNCc=

Go info

go version go1.13 linux/amd64

GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/jake/.cache/go-build"
GOENV="/home/jake/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/jake/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/jake/zikaeroh/hortbot/hortbot/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-build514825024=/tmp/go-build -gno-record-gcc-switches"

cc @muirrn
@gopherbot gopherbot added this to the Unreleased milestone Sep 19, 2019
@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 Sep 19, 2019
@golang golang deleted a comment from gopherbot Sep 19, 2019
@muirdm
Copy link

muirdm commented Sep 19, 2019

Thanks for noticing this. Coincidentally I was just working on a fix to prefer type names in this situations. Let me push it.

Note that even with my change it is still possible to get non-type completion items. Even if we expect a type name, we don't exclude non-type items, so they can still show up.

@zikaeroh
Copy link
Contributor Author

zikaeroh commented Sep 19, 2019 •
edited

Are there any situations where completions that don't look like <type> or <package>.<type> would bring more types in? I'd think it's safe to exclude anything that isn't referring to a type in the current scope or another package, but maybe you're erring on the side of sorting rather than hiding bad completions (which is totally understandable, perhaps preferred).

@gopherbot
Copy link

Change https://golang.org/cl/196560 mentions this issue: internal/lsp: improve completions in *ast.FieldList

@muirdm
Copy link

muirdm commented Sep 19, 2019

I'd think it's safe to exclude anything that isn't referring to a type

Yes, I think you are right. As long as we are 100% confident a type name is required, we can exclude non-type candidates.

maybe you're erring on the side of sorting rather than hiding bad completions

That is definitely true also. If things are sorted properly there isn't much of a downside to including more candidates. We'll eventually be smarter about this.

Please give my CL a try and see if it makes a difference. You might need the first CL in the series as well to merge cleanly.

@golang golang locked and limited conversation to collaborators Sep 24, 2020
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. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Milestone
Unreleased
Development

No branches or pull requests
3 participants
@gopherbot @muirdm @zikaeroh