x/tools/gopls: support fill struct behavior

[frioux]

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

$ go version
go version go1.14 linux/amd64

Does this issue reproduce with the latest release?

n/a (feature request)

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

go env Output

$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/frew/.cache/go-build"
GOENV="/home/frew/.config/go/env"
GOEXE=""
GOFLAGS="-mod=readonly"
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/frew/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org"
GOROOT="/home/frew/sdk/go1.14"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/frew/sdk/go1.14/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
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=/run/shm/go-build445574914=/tmp/go-build -gno-record-gcc-switches"

What did you do?

n/a (feature request)

What did you expect to see?

n/a (feature request)

What did you see instead?

n/a (feature request)

Feature request

vim-go had a command called :GoFillStruct and it would transform (for example), this:

x := Person{}

into

x := Person{
	Name: "",
	Employed: false,
	Age: 0,
}

Basically it'd set all the fields to their zero value. In govim/govim#709 I was told that this needs to be added to gopls first, so here I am :)

[stamblerre]

Thanks for the issue report! I agree that we should support this feature.

@muirdm: Do you think we could fit this behavior into completion?

[muirdm]

For my understanding, what is the use case for this?

[stamblerre]

I don't know if it's particularly useful for the Person case described above, but I would find it useful if the struct contained map values. (My classic example is go/types.Info, which I always find super annoying to create.) My ideal scenario when completing that struct is that, if I have a value of the correct type in scope, it should be used -- otherwise, we should make a map in the struct declaration.

[muirdm]

The zero value of map is "nil", so this proposal as written wouldn't help in the types.Info case.

In my experience having the literal completion that gives you a candidate for make(map[some.Long]annoying.Map) is already a major improvement. Having structs get automatically filled in with in-scope objects sounds hard to avoid false positives.

[frioux]

the main use case here is creating fresh struct with lots of fields. This is common when working with, for example, the aws sdk where completing methods is a very small help since you then need to pass in a struct with sometimes dozens of fields set.

…

On Mon, Mar 2, 2020, 1:19 PM Muir Manders ***@***.***> wrote: The zero value of map is "nil", so this proposal as written wouldn't help in the types.Info case. In my experience having the literal completion that gives you a candidate for make(map[some.Long]annoying.Map) is already a major improvement. Having structs get automatically filled in with in-scope objects sounds hard to avoid false positives. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#37576?email_source=notifications&email_token=AAAB7Y5OHXJKRI2XLFM4CA3RFQPGNA5CNFSM4K6CIMAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENRAR5Q#issuecomment-593627382>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAB7YYIU35CO53T5KJSNV3RFQPGNANCNFSM4K6CIMAA> .

[muirdm]

I can see how that could be part of your workflow, but it also seems to overlap with existing facilities such as textDocument/hover which will show you all the struct fields or just a normal completion request in the struct literal, which also will list all the struct fields and their types.

To answer the original question of fitting this into completion, we could but I'm not sure what would trigger the completion or how it would show up clearly to the user. Maybe better as a code action?

[frioux]

I don't know what a code action is, but in the original setting it was something the user would explicitly request, rather than fitting into the same workflow as method completion. I personally think that's fine; this is something I'd do a few times a day, not constantly, like method completion.