x/tools/gopls: configuration ignored

[jech]

Go version

go version go1.21.6 linux/amd64

Output of go env in your module/workspace:

GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/jch/.cache/go-build'
GOENV='/home/jch/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/jch/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/jch/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/lib/go-1.21'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/lib/go-1.21/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.21.6'
GCCGO='/usr/bin/gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/home/jch/go/src/github.com/jech/galene/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build2905991881=/tmp/go-build -gno-record-gcc-switches'

What did you do?

I have the following in my eglot configuration:

(setq-default eglot-workspace-configuration
              '(:gopls (:analyses (:composites :json-false))))

This works fine with gopls 0.16, but doesn't seem to do anything useful in gopls 0.17.

What did you see happen?

With gopls 0.17, Emacs displays diagnostics about unkeyed composites. WIth gopls 0.16, composites diagnostics are correctly suppressed.

What did you expect to see?

No composites diagnostics in both 0.16 and 0.17.

[findleyr]

Hi, the latest version of gopls is v0.14.2. What do you mean by 0.16 and 0.17?
https://pkg.go.dev/golang.org/x/tools/gopls?tab=versions

[jech]

The versions of gopls currently in Debian are the following:

• Debian testing has gopls version 1:0.16.1+ds-1
• Debian unstable has gopls version 1:0.17.0+ds-1

I have no idea how the Debian versions relate to the upstream versions, but I see that the tools git repository has tags called v0.16.1 v0.17.0, so I've assumed that these are also the upstream versions.

[findleyr]

Aha, @jech those are versions for the x/tools module. Versions of the nested x/tools/gopls module correspond to tags like gopls/v0.14.2. x/[email protected] contains commits that have not yet been included in the latest gopls release.

Therefore, you may indeed be observing a regression. We will investigate.

Thank you for reporting. We're preparing the [email protected] release, and you may have caught a bug.

[findleyr]

Hmm, however I'm not able to reproduce, even when installing gopls at the v0.17.0 commit of x/tools. I am able to successfully suppress composites. Logs from a short gopls session would help me diagnose further. For example, I'll be able to see whether the editor is successfully sending settings to gopls. Beware that these logs may contain source code.

[jech]

Logs from a short gopls session would help me diagnose further.

https://www.irif.fr/~jch/gopls-composites.tar.gz

[findleyr]

Hi, we've now had three reports for this behavior, all related to emacs. I think we broke the configuration workflow in a way that affects only emacs. I'll investigate and fix. Thank you for reporting!

[findleyr]

Thanks very much for the logs -- looking at them it appears that eglot has always been returning an error from one of our configuration requests, and it may be that our handling of this error changed.

I've set up emacs+eglot and reproduced, so I've got it from here.

[gopherbot]

Change https://go.dev/cl/563475 mentions this issue: gopls/internal/server: fix two bugs related to dynamic configuration

[jech]

Thanks a lot.

Since Emacs didn't complain, does that indicate there's a bug in eglot? If so, could you please either file a bug against eglot, or give me enough details so I can do it myself?

[findleyr]

@jech I don't think there's a bug in eglot. There were two bugs in gopls, as described in the CL above. The pre-existing bug is that gopls was sending "" instead of omitting a field in a configuration request. Many clients (particularly javascript-based clients) were tolerant of this, but Emacs was not. I think Emacs is right. The new bug in gopls broke what was previously masking the old bug. Both bugs are now fixed at tip.

[jech]

Cool, thanks for the clarification.