cmd/go: go get golang/x/tools/...: no matching versions for query "latest"

[wsc1]

Please answer these questions before submitting your issue. Thanks!

What did you do?

If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.

go get golang.org/x/tools/...

What did you expect to see?

success

What did you see instead?

⎣ ⇨ go get -u -v golang.org/x/tools/...
Fetching https://golang.org/x/tools?go-get=1
Parsing meta tags from https://golang.org/x/tools?go-get=1 (status code 200)
get "golang.org/x/tools": found meta tag get.metaImport{Prefix:"golang.org/x/tools", VCS:"git", RepoRoot:"https://go.googlesource.com/tools"} at https://golang.org/x/tools?go-get=1
go: finding golang.org/x/tools/... latest
Fetching https://golang.org/x/tools?go-get=1
Parsing meta tags from https://golang.org/x/tools?go-get=1 (status code 200)
get "golang.org/x/tools": found meta tag get.metaImport{Prefix:"golang.org/x/tools", VCS:"git", RepoRoot:"https://go.googlesource.com/tools"} at https://golang.org/x/tools?go-get=1
go: finding golang.org/x/tools latest
Fetching https://golang.org/x?go-get=1
Parsing meta tags from https://golang.org/x?go-get=1 (status code 200)
Fetching https://golang.org?go-get=1
Parsing meta tags from https://golang.org?go-get=1 (status code 200)
go get golang.org/x/tools/...: no matching versions for query "latest"

System details

go version go1.11 darwin/amd64
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/scott/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/scott/Dev/zic"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/scott/Dev/zic/src/zikichombo.org/sound/go.mod"
GOROOT/bin/go version: go version go1.11 darwin/amd64
GOROOT/bin/go tool compile -V: compile version go1.11
uname -v: Darwin Kernel Version 17.7.0: Thu Jun 21 22:53:14 PDT 2018; root:xnu-4570.71.2~1/RELEASE_X86_64
ProductName:	Mac OS X
ProductVersion:	10.13.6
BuildVersion:	17G65
lldb --version: lldb-902.0.79.7
  Swift-4.1

[bradfitz]

Do you have GO111MODULE set to "on" ?

[wsc1]

yes, it was. GO111MODULE=off works ok.

Also, GOMOD was set, which I think should mean it was enabled by some mechanism or other.

[rkuska]

Same is happening here:

$ go get -u github.com/go-critic/go-critic/...                                                                                                                                                                                                                
go: finding github.com/go-critic/go-critic/... latest
go: finding github.com/go-critic/go-critic latest
go get github.com/go-critic/go-critic/...: no matching versions for query "latest"                                                                                                                                                                                                                
$ go version                                  
go version go1.11 darwin/amd64

[ivanalejandro0]

I had the same (or very similar) problem building a module and using GO111MODULE=off wasn't an option for me since I wanted to use modules.
I solved this running go clean -modcache.

[bcmills]

I think the go tool is ending up interpreting the /... as part of the package path instead of a pattern.

Note that in module mode, ... patterns match packages in active modules, so it doesn't really make sense to go get -u one of those patterns unless you've already got those packages in your module dependencies. It would be helpful to see the output of go list golang.org/x/tools/... or go list github.com/go-critic/go-critic/... before you ran go get -u.

[bcmills]

@ivanalejandro0 I would be surprised if an issue fixable by go clean -modcache is the same as the one involving ... patterns.

[ivanalejandro0]

@ivanalejandro0 I would be surprised if an issue fixable by go clean -modcache is the same as the one involving ... patterns.

Yeah, I agree.
My problem didn't involve any ..., but @wsc1 said that with "GO111MODULE=off works ok", so I figured it may be worth mentioning.

[cloudlena]

I can confirm @rkuska's issue with go-critic and have it documented in this Travis build.