cmd/go: 'go mod download' can't request version of the main module

[jayconrod]

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

$ go version
go version devel +8f2db14cd3 Tue Nov 10 18:42:47 2020 +0000 darwin/amd64

Does this issue reproduce with the latest release?

No, this is a regression.

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

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/jayconrod/Library/Caches/go-build"
GOENV="/Users/jayconrod/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/jayconrod/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/jayconrod/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/jayconrod/Code/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/jayconrod/Code/go/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="devel +8f2db14cd3 Tue Nov 10 18:42:47 2020 +0000"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/jayconrod/Code/test/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/rq/x0692kqj6ml8cvrhcqh5bswc008xj1/T/go-build788352896=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

go mod init rsc.io/quote
go mod download rsc.io/quote@v1.5.2

What did you expect to see?

The module version specified on the command line is downloaded regardless of whether its path is the same as the main module.

What did you see instead?

rsc.io/quote@v1.5.2: can't request version "v1.5.2" of the main module (rsc.io/quote)

[bcmills]

This regressed at CL 258220: we had been hitting the “direct lookup” special case before the main-module check, and now we're doing the main-module check before the repo lookup.

The main-module check seems kind of out-of-place in the query functions anyway. A holistic fix might be to move the “main module” logic out of modload.queryProxy and into modload.queryImport.

It appears that I already shored up the modget side of things in CL 263267: (*modget.resolver).disambiguate already avoids conflicting versions of the main module and (*modget.resolver).resolve already reports errors for them.

[gopherbot]

Change https://golang.org/cl/270520 mentions this issue: cmd/go: allow querying other versions of the main module

[gopherbot]

Change https://golang.org/cl/270860 mentions this issue: cmd/go: allow querying other versions of the main module