你正在使用哪个版本的Go(go version)?
$ go version
go version go1.14rc1 linux/amd64这个问题在最新版本中是否会重现？
是的。
你正在使用什么操作系统和处理器架构(go env)?
go env 输出
$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN="/home/manlio/.local/bin"
GOCACHE="/home/manlio/.cache/go-build"
GOENV="/home/manlio/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/manlio/.local/lib/go:/home/manlio/src/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/manlio/sdk/go1.14rc1"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/manlio/sdk/go1.14rc1/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
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-build552987847=/tmp/go-build -gno-record-gcc-switches"
GOROOT/bin/go version: go version go1.14rc1 linux/amd64
GOROOT/bin/go tool compile -V: compile version go1.14rc1
uname -sr: Linux 5.5.4-arch1-1
/usr/lib/libc.so.6: GNU C Library (GNU libc) stable release version 2.31.
gdb --version: GNU gdb (GDB) 9.1你做了什么？
在一个模块内部 github.com/perillo/goprint :
$ go list -m ""你期望看到什么？
github.com/perillo/goprint你看到了什么？
go list -m: module : not a known dependencygo list "" 可以正常工作。这种不对称性有什么原因吗？
如果一个空的模块路径必须被拒绝，那么错误信息应该被更改。
谢谢。
7条答案
按热度按时间vjrehmav1#
go list ""运行正常。这种不对称现象有什么原因吗？这看起来像是
go list在没有-m的情况下的bug。如果必须拒绝空模块路径，那么错误信息应该进行更改。
同意：我们应该修复
go list -m的错误信息。CC @jayconrod@matloob
11dmarpk2#
go list ""可能很方便。https://godoc.org/golang.org/x/tools/go/packages包使用了函数,但如果一个程序只期望一个包，它可能使用
。
lrl1mhuk3#
go list .的定义是明确的。而go list ""的定义是不明确的：空字符串不是一个有效的包模式。2fjabf4q4#
go list的一些不带-m的示例：当它们不在模块内时，会返回错误：
这意味着
""被当作"."处理。cdmah0mi5#
这些例子与
""解析为与.相同的情况是一致的。我认为不需要单独的问题。(我怀疑相同的 CL 可以轻松涵盖这两种情况，如果不是，我们可以在那时分叉另一个问题。)lqfhib0f6#
@bcmills: 我们这里有两个不同的问题吗？
2nbm6dog7#
这两个症状都源于同一个根本原因：在解析参数时未能诊断空字符串参数。