cmd/go: regression of module resolution behaviour

[rogpeppe]

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

$ go version
go version devel +ab724d43ef Mon May 20 20:58:14 2019 +0000 linux/amd64

On tip, module pseudo-version resolution does not seem to work correctly in some cases where it works OK under Go 1.12.

I'm using git version 2.21.0.

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

go env Output

$ go env
GO111MODULE="auto"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/rog/.cache/go-build"
GOENV="/home/rog/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/rog/src/go"
GOPROXY="direct"
GOROOT="/home/rog/go"
GOSUMDB="off"
GOTMPDIR=""
GOTOOLDIR="/home/rog/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/rog/go/src/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-build080092268=/tmp/go-build -gno-record-gcc-switches"

Here's a program that resolves a dependency to a pseudo-version: https://play.golang.org/p/C-wGtbN2TwA

Under Go 1.12 (or the playground) produces this result:

github.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc

This is expected. Commit d8f796af33cc has v1.1.1 in its history, so the pseudo-version should include the latest predecessor version.

Under tip, I see this result:

github.com/davecgh/go-spew v0.0.0-20180830191138-d8f796af33cc

It seems that the logic for determining predecessor versions is no longer working correctly.

[rogpeppe]

Here's another test case that doesn't do the right thing AFAICS, although this one fails under Go 1.12 too:

https://play.golang.org/p/qDuD3BjVlmx

Note that commit 623b5a2f4d2a has v2.0.5 in its history, so I think the resulting version should be v2.0.6-0.20181027085611-623b5a2f4d2a+incompatible, not v0.0.0-20181027085611-623b5a2f4d2a.

[bcmills]

I can't reproduce the observed behavior with a clean module cache:

example.com$ gotip version
go version devel +ab724d43 Mon May 20 20:58:14 2019 +0000 linux/amd64

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

example.com$ gotip get github.com/davecgh/go-spew@d8f796af33cc
go: finding github.com/davecgh/go-spew d8f796af33cc
go: downloading github.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc
go: extracting github.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc

I suspect that you've got a v0.0.0-* entry in your module cache, perhaps due to an older pseudo-version specified in the (transitive) requirements of some module you've built previously. If so, that would make this another instance of #27171. Could you confirm?

[bcmills]

The v2.0.6-[…]+incompatible issue is #29262.

[rogpeppe]

I've just tried it again this morning and I can no longer reproduce the issue, sadly. I haven't changed my cache settings. There's something odd going on. For future reference though, when you talk about the "module cache", you're talking about what's in $GOPATH/pkg, not $GOCACHE, right?

I'll close the issue for now.

[bcmills]

For future reference though, when you talk about the "module cache", you're talking about what's in $GOPATH/pkg, not $GOCACHE, right?

Correct.