cmd/go: 'get xxx@latest' does not report mismatch between module path and major version

[XuHuaiyu]

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

$ go version
go version go1.12 darwin/amd64

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
GOARCH="amd64"
GOBIN="/Users/xuhuaiyu/Development/GOPATH/bin"
GOCACHE="/Users/xuhuaiyu/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/xuhuaiyu/Desktop/gopath"
GOPROXY=""
GORACE=""
GOROOT="/Users/xuhuaiyu/.gvm/gos/go1.12"
GOTMPDIR=""
GOTOOLDIR="/Users/xuhuaiyu/.gvm/gos/go1.12/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/xuhuaiyu/Desktop/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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/ck/7tvksj1s7cl6djwl1j6kd67m0000gn/T/go-build099338216=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

$ GO111MODULE=on go get github.com/pingcap/tidb@latest

What did you expect to see?

github.com/pingcap/tidb v2.1.5

What did you see instead?

go: extracting github.com/pingcap/tidb v2.0.11+incompatible

[agnivade]

/cc @bcmills

[justinruggles]

I believe the issue is that the tidb module name does not include the /v2 to indicate major version 2

[bcmills]

@justinruggles has the right root cause, but we could certainly do a better job of diagnosing the problem.

CC @jayconrod

[jayconrod]

go release (#26420) will warn module authors about this before tagging new versions. I think that's the main solution for this.

go get could print a warning here for the latest semantic version if it has a go.mod file with a module path that doesn't match the semantic version.

In most cases though, when authors add go.mod files after a v2 version, they'll use a /v2 suffix. We shouldn't print an error message for that when looking for the latest version of the module without a suffix.

[bcmills]

At head, go get will report the error for an explicit version, but will fall back to the latest valid version for latest. (Note the use of GOPROXY=direct to work around invalid versions cached in the module proxy; see #32805.)

Perhaps we should report an explicit error at that point instead of falling back.

example.com$ gotip mod init example.com
go: creating new go.mod: module example.com

example.com$ gotip version
go version devel +39d41787 Wed Jul 31 05:45:43 2019 +0000 linux/amd64

example.com$ GOPROXY=direct gotip get github.com/pingcap/tidb@v2
go: finding github.com/pingcap/tidb v2.0.11+incompatible
go: downloading github.com/pingcap/tidb v2.0.11+incompatible
go: extracting github.com/pingcap/tidb v2.0.11+incompatible

example.com$ GOPROXY=direct gotip get github.com/pingcap/tidb@v2.1.5
go: finding github.com/pingcap/tidb v2.1.5
go get github.com/pingcap/tidb@v2.1.5: github.com/pingcap/tidb@v2.1.5: invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v2

example.com$

[jayconrod]

In 1.17.2, the go command correctly figures out that v2.0.11+incompatible is the @latest versions. If a specific invalid version is requested:

go list -m: github.com/pingcap/tidb@v2.1.5: invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v2

Looks like this is resolved.