cmd/go: workspace recursive add should skip malformed module definitions

[sding3]

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

$ go version
go version go1.18 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=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/shang/.cache/go-build"
GOENV="/home/shang/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/shang/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/shang/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.18"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK="/home/shang/go/src/go.work"
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-build895139390=/tmp/go-build -gno-record-gcc-switches"

What did you do?

mkdir /tmp/reproduce-issue/
cd /tmp/reproduce-issue/
git clone https://go.googlesource.com/tools
go work init
go work use -r .

cat <<EOF > hello.go
package main
import "fmt"
func main() {
    fmt.Println("hello world")
}
EOF

go run hello.go

What did you expect to see?

Expected to see a functional workspace to be created, which should have no effect over the final go run hello.go command.

What did you see instead?

An un-usable workspace was created due to the tools repo containing some purposefully invalid go.mod files meant for unit testing, which go work use -r . added to the workspace, causing the final go run hello.go command to fail with:

go: malformed module path "αfake1α": invalid char 'α'

go work use -r should probably print a warning message for each malformed module definition that it encounters instead of adding those to the workspace.

[seankhliao]

maybe it should instead be ignoring everything in testdata/ s

cc @bcmills @matloob

[sding3]

Another approach, orthogonal to your ignore testdata/ suggestion, is to add a -maxdepth <int> flag to the go work use -r command to limit the search scope of the recursive directory descend.

[bcmills]

go.mod files in testdata directories prune that testdata out of the resulting module (see also #27852), which will likely either cause the test to become a no-op (and thus miss real bugs) or cause the test to always fail (and produce spurious failures in, say, go test all that can be a nuisance to filter out).

For the foreseeable future, tests which require their own go.mod file will need to construct the module within a temp directory instead of relying on it in a testdata subdirectory.