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

$ go version
go version devel +6f7b96f6cb Sat Nov 23 11:00:41 2019 +0000 linux/amd64
$ go list -m golang.org/x/tools
golang.org/x/tools v0.0.0-20191113223546-95cb2a1a7eae => github.com/myitcvforks/tools v0.0.0-20191119111301-0222b4b716c6
$ go list -m golang.org/x/tools/gopls
golang.org/x/tools/gopls v0.1.8-0.20191115202509-3a792d9c32b2 => github.com/myitcvforks/tools/gopls v0.0.0-20191119111301-0222b4b716c6

Note that github.com/myitcvforks/tools v0.0.0-20191119111301-0222b4b716c6 and github.com/myitcvforks/tools/gopls v0.0.0-20191119111301-0222b4b716c6 correspond to the x/tools 95cb2a1 with 80313e1 cherry picked on top. Reason being, we can't move beyond 95cb2a1 because otherwise we start tripping over the mistmatched versions problem described in #35114

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=""
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"
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-build765461991=/tmp/go-build -gno-record-gcc-switches"

What did you do?

We have a govim test that is looking to verify the behaviour of setting the "env" config setting with GOFLAGS=-mod=reaonly.

However the issue we are seeing is that the initial Configuration call from gopls to govim happens as follows:

• govim -> gopls: Initialize()
• govim -> gopls: Initialized() (notification)
• govim -> gopls: didOpen("main.go")
• govim -> gopls: didChange("main.go")
• gopls -> govim: Configuration()

i.e. it's not happening as part of handling the Initialized notification from govim.

What did you expect to see?

This doesn't appear to be specified in the LSP spec https://microsoft.github.io/language-server-protocol/specifications/specification-3-14/#initialized but not calling Configuration as part of handling the Initialized notification means that the client has no way of registering configuration that should be applied "from the start".

e.g. in this case, setting "env" to include GOFLAGS=-mod=reaonly. If this does not happen during the handling of Initialized then the go.mod file will likely already have been modified by the time the results of Configuration come to be processed.

One could argue that the client could instead send the DidChangeConfiguration notification immediately after Initialized but this is not specified either, so we can't be guaranteed that all clients will do this. Whereas calling Configuration as part of the handling of Initialized (not afterwards because otherwise this creates a race) seems safe.

What did you see instead?

As above.

gopls log as follows:
fail.log

cc @stamblerre