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: inconsistent behaviour with GOFLAGS=-mod=readonly set #36789

Open
myitcv opened this issue Jan 27, 2020 · 1 comment
Open

x/tools/gopls: inconsistent behaviour with GOFLAGS=-mod=readonly set #36789

myitcv opened this issue Jan 27, 2020 · 1 comment

Comments

@myitcv
Copy link
Member

@myitcv myitcv commented Jan 27, 2020

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

$ go version
go version devel +73d213708e Sat Jan 25 16:34:18 2020 +0000 linux/amd64
$ go list -m golang.org/x/tools
golang.org/x/tools v0.0.0-20200124220429-8fe064f891f2
$ go list -m golang.org/x/tools/gopls
golang.org/x/tools/gopls v0.1.8-0.20200124220429-8fe064f891f2

Does this issue reproduce with the latest release?

Yes

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

go env Output
$ 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-build912581415=/tmp/go-build -gno-record-gcc-switches"

What did you do?

We have a govim test that verifies the setting of the "env" value GOFLAG=-mod=readonly. It is based on the following setup:

-- go.mod --
module mod.com

go 1.13
-- main.go --
package main

import "example.com/blah"

func main() {
	println(blah.Name)
}

(example.com/blah is a valid module and is accessible).

We initially verify that we have the following diagnostic:

PublishDiagnostics callback: &protocol.PublishDiagnosticsParams{
    URI:         "file:///tmp/go-test-script844433945/script-config_set_env_goflags_mod_readonly/main.go",
    Version:     1,
    Diagnostics: {
        {
            Range: protocol.Range{
                Start: protocol.Position{Line:2, Character:7},
                End:   protocol.Position{Line:2, Character:25},
            },
            Severity:           1,
            Code:               nil,
            Source:             "compiler",
            Message:            "could not import example.com/blah (no package for import example.com/blah)",
            Tags:               nil,
            RelatedInformation: nil,
        },
    },If applicable, copy/paste the text or add screenshots to help explain your problem.

}

However we often (~50% of the time, which is actually 100% of the time on CI, I can't reproduce locally) do not receive this diagnostic.

The following errors are logged by gopls:

Params: {"type":1,"message":"2020/01/26 21:52:32 diagnose: no workspace packages: go [-e -json -compiled=true -test=true -export=false -deps=true -find=false -- ./... builtin]: exit status 1: build mod.com: cannot load example.com/blah: import lookup disabled by -mod=readonly\n\n\tdirectory = 0xa932b0"}

What's interesting is that when this test passes we do not see this or any errors logged by gopls.

Given I can't repro this locally it suggests there's an element of timing involved.

What did you expect to see?

Consistently receiving an initial diagnostic from gopls for main.go

What did you see instead?

As above.

Marking as v1.0.0 because this isn't critical for v0.3.0 to my mind.


cc @stamblerre

FYI @leitzler

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented Jan 28, 2020

Agreed that this is not critical for v0.3.0. It looks like we are getting the error message from the initialization go list and not presenting it as a diagnostic.

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.