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: 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
Milestone

Comments

@zikaeroh
Copy link

@zikaeroh zikaeroh commented Sep 19, 2019

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
@golang golang deleted a comment from gopherbot Sep 19, 2019
@muirdm

This comment has been minimized.

Copy link

@muirdm 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

This comment has been minimized.

Copy link
Author

@zikaeroh zikaeroh commented Sep 19, 2019

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

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Sep 19, 2019

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

@muirdm

This comment has been minimized.

Copy link

@muirdm 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.