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

$ go version
go version devel +5d9549debb Thu May 7 02:47:46 2020 +0000 linux/amd64
$ go list -m golang.org/x/tools
golang.org/x/tools v0.0.0-20200509030707-2212a7e161a5
$ go list -m golang.org/x/tools/gopls
golang.org/x/tools/gopls v0.0.0-20200509030707-2212a7e161a5

Does this issue reproduce with the latest release?

Yes

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

$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/myitcv/.cache/go-build"
GOENV="/home/myitcv/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/myitcv/gostuff/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/myitcv/gostuff"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/myitcv/gos"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/myitcv/gos/pkg/tool/linux_amd64"
GCCGO="gccgo"
GOAMD64="alignedjumps"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/myitcv/gostuff/src/github.com/myitcv/govim/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-build041272007=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Currently, when a client notifies the server of a DidChangeConfiguration, gopls makes a Configuration call to the client for each View (workspace):

https://github.com/golang/tools/blob/aaeff5de670acfcdd4758eaea55e2a86ca6ac802/internal/lsp/workspace.go#L47-L57

Each call is made with a []protocol.ConfigurationItem of length 2. The first item is a section named "gopls", the second is named according to the format "gopls-$VIEWNAME".

The client should respond with n <= 2 configuration maps corresponding to the []protocol.ConfigurationItem sent.

The configuration for each view is then determined as follows: take the current session configuration (set at Initialize time), then apply each of the configuration maps returned by the client. In effect there is a cascade, with the more specific "gopls-$VIEWNAME" configuration map "winning". The "gopls" section can be considered a "default workspace" config.

There are three issues that arise from this setup:

1. it is not possible to update the session options post Initialize
2. a minor efficiency point, more Configuration calls are made than is necessary
3. the meaning of the "gopls" section is somewhat confused by the fact that a different value can be returned for the n Configuration calls corresponding to n workspaces (views)

This issue is primarily about fixing the first of these points. A client should be able to update the session options post Initialize.

Perhaps one way of achieving this would be for a Configuration call from server to client to pass []protocol.ConfigurationItem with the following sections:

"session"            // the session options
"gopls"              // the default workspace settings
"gopls-workspace1"   // the specific workspace settings for workspace1
"gopls-workspace2"   // the specific workspace settings for workspace2
...

Clearly this will need some thought with respect to the various gopls clients, so the idea above is really just to kick-start discussion.

cc @stamblerre @findleyr @hyangah