cmd/go: get -d $mod@$version fails if there is no package/source files

[myitcv]

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

$ go version
go version go1.16rc1 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 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=""
GOMODCACHE="/home/myitcv/gostuff/pkg/mod"
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"
GOVCS=""
GOVERSION="go1.16rc1"
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-build1840501271=/tmp/go-build -gno-record-gcc-switches"

What did you do?

cd $(mktemp -d)
go mod init blah
go get -d cuelang.org/go@611d622721dd0cb390728a065902414346fe8558

What did you expect to see?

No error, per Go 1.15.7

What did you see instead?

cuelang.org/go: no Go source files

I guess the challenge here is that it doesn't make sense for:

go get -d cuelang.org/go/absoluterubbish@611d622721dd0cb390728a065902414346fe8558

to not return an error.

But I think a special case for go get -d $mod[@$version] is fine.

cc @bcmills @jayconrod

[myitcv]

Bisected to 06538fa in case that's useful.

[bcmills]

Thanks. #29268 is closely related (with a test-only package rather than a tag-only package).

[bcmills]

I think we should fix this, but it's not obvious to me that it needs to block the 1.16 release, and whether it makes 1.16 at all probably depends on how invasive the fix is.

Note that a workaround in the meantime is to explicitly provide some set of tags that is sufficient for the package to exist:

$ go version
go version devel +8869086d8 Thu Feb 4 04:46:49 2021 +0000 linux/amd64

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

$ go get -d cuelang.org/go@611d622721dd0cb390728a065902414346fe8558
go: downloading cuelang.org/go v0.3.0-beta.3.0.20210204095639-611d622721dd
go: downloading golang.org/x/tools v0.0.0-20200612220849-54c614fe050c
go: downloading golang.org/x/exp v0.0.0-20210126221216-84987778548c
go: downloading golang.org/x/mod v0.3.1-0.20200828183125-ce943fd02449
go: downloading golang.org/x/xerrors v0.0.0-20191204190536-9bdfabe68543
cuelang.org/go: no Go source files

$ go get -d -tags=tools cuelang.org/go@611d622721dd0cb390728a065902414346fe8558
go get: added cuelang.org/go v0.3.0-beta.3.0.20210204095639-611d622721dd

CC @matloob

[gopherbot]

Change https://golang.org/cl/289769 mentions this issue: cmd/go: suppress errors from 'go get -d' for packages that only conditionally exist