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

$ go version
go version devel +07c1788357 Fri Sep 11 18:14:49 2020 +0000 linux/amd64

Does this issue reproduce with the latest release?

No, this works fine in Go 1.15. On tip, it fails.

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

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/jake/.cache/go-build"
GOENV="/home/jake/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/jake/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/jake/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/jake/sdk/gotip"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/jake/sdk/gotip/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/jake/zikaeroh/hortbot/hortbot/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-build245809118=/tmp/go-build -gno-record-gcc-switches"
GOROOT/bin/go version: go version devel +07c1788357 Fri Sep 11 18:14:49 2020 +0000 linux/amd64
GOROOT/bin/go tool compile -V: compile version devel +07c1788357 Fri Sep 11 18:14:49 2020 +0000
uname -sr: Linux 5.8.8-zen1-1-zen
/usr/lib/libc.so.6: GNU C Library (GNU libc) release release version 2.32.
gdb --version: GNU gdb (GDB) 9.2

What did you do?

This is a cut down version of something I see in one of my projects, where some dependency of a dependency (and so on) causes this.

package main

import _ "github.com/spf13/viper"

func main() {}

And a go.mod:

module some.tld/golistall

go 1.15

require github.com/spf13/viper v1.7.1

Run go list -u -m all.

What did you expect to see?

A listing of all modules, with possible upgrades listed. This command is used by tooling like gopls to offer upgrades as well.

What did you see instead?

go list -m: loading module retractions: github.com/coreos/bbolt@v1.3.5: parsing go.mod:
	module declares its path as: go.etcd.io/bbolt
	        but was required as: github.com/coreos/bbolt

viper requires github.com/coreos/bbolt@v1.3.2, which predates the addition of a go.mod. When this fork of bolt was turned into a module, it gained the new import path go.etcd.io/bbolt. I'm assuming that this breaks down with -u because it's scanning newer versions and finding the mismatch.

Normally, I'd say "viper should update its use to the new module path", but I'm not sure that this is going to really fix the issue if these sorts of mismatches are living happily in the wild. The code still builds, but it causes anyone who depends on it to no longer be able to run go list -u -m all seemingly without much recourse in a situation that worked in previous versions of Go.

I bisected the issue, assuming it was something related to the new all changes, but it's actually the -retracted CL. (On reflection, I didn't read the error message closely enough; it says "loading module retractions" right there!)

eb3e27ac1a9346c7c2669ba2b863811607eddeae is the first bad commit
commit eb3e27ac1a9346c7c2669ba2b863811607eddeae
Author: Jay Conrod <jayconrod@google.com>
Date:   Wed Apr 15 14:42:15 2020 -0400

    cmd/go: add -retracted flag to 'go list'
    
    The -retracted flag causes 'go list' to load information about
    retracted module module versions.
    
    When -retracted is used with -f or -json, the Retracted field is set
    to a string containing the reason for the retraction on retracted
    module versions. The string is based on comments on the retract
    directive. This field is also populated when the -u flag is used.
    
    When -retracted is used with -versions, retracted versions are shown.
    Normally, they are omitted.
    
    For #24031
    
    Change-Id: Ic13d516eddffb1b8404e21034f78cecc9896d1b8
    Reviewed-on: https://go-review.googlesource.com/c/go/+/228382
    Reviewed-by: Michael Matloob <matloob@golang.org>
    Reviewed-by: Bryan C. Mills <bcmills@google.com>

I'll preemptively cc @jayconrod and @bcmills, if that's okay. 🙂