cmd/go: 'mod tidy' chooses points in requirement cycles that differ from other subcommands

[bcmills]

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

~/go/src$ go version
go version devel +1452119867 Tue Sep 3 21:10:31 2019 +0000 linux/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/src$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/usr/local/google/home/bcmills/.cache/go-build"
GOENV="/usr/local/google/home/bcmills/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/usr/local/google/home/bcmills"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/google/home/bcmills/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/google/home/bcmills/go/pkg/tool/linux_amd64"
GCCGO="/usr/local/google/home/bcmills/bin/gccgo"
AR="ar"
CC="gcc"
CXX="c++"
CGO_ENABLED="1"
GOMOD="/usr/local/google/home/bcmills/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-build607708420=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Added a new cmd/go/testdata/script test case, derived from https://github.com/prochac/mod-fmt-issue (H/T @prochac).

env GO111MODULE=on

cp go.mod go.mod.orig
go mod tidy
cmp go.mod go.mod.orig

# If the go.mod file is already tidy, 'go mod graph' should not modify it.
go mod graph
cmp go.mod go.mod.orig

-- go.mod --
module root

go 1.13

replace (
	a v0.1.0 => ./a1
	b v0.1.0 => ./b1
	b v0.2.0 => ./b2
	c v0.1.0 => ./c1
	c v0.2.0 => ./c2
)

require (
	a v0.1.0
	c v0.2.0 // indirect
)
-- main.go --
package main

import _ "a"

func main() {}

-- a1/go.mod --
module a

go 1.13

require b v0.1.0
-- a1/a.go --
package a

import _ "c"
-- b1/go.mod --
module b

go 1.13

require c v0.1.0
-- b2/go.mod --
module b

go 1.13

require c v0.2.0
-- c1/go.mod --
module c

go 1.13
-- c2/c.go --
package c
-- c2/go.mod --
module c

go 1.13

require b v0.2.0
-- c2/c.go --
package c

What did you expect to see?

After go mod tidy completes successfully, go mod graph should not modify the go.mod file.

What did you see instead?

go mod tidy and go mod graph pick different points to retain in the cycle between b v0.2.0 and c v0.2.0. (At least one point is necessary, and either is valid, so the choice is arbitrary — however, they should both pick the same one.)

[bcmills]

CC @jayconrod @myitcv @thepudds

[gopherbot]

Change https://golang.org/cl/193397 mentions this issue: cmd/go/internal/mvs: recompute build list in Reqs before minimizing