x/tools/goimports panic: runtime error: index out of range [1] with length 0

[tendervittles]

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

$ go version
go version go1.13rc2 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/tendervittles/.cache/go-build"
GOENV="/home/tendervittles/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/tendervittles/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/other/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/other/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/tendervittles/go/pkg/mod/golang.org/x/tools@v0.0.0-20190830223141-573d9926052a/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-build909966219=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Ran goimports -local myorg.com -w on a few go files.

It might be a red herring, but one of go files does contain some cgo.

What did you expect to see?

No panic

What did you see instead?

panic: runtime error: index out of range [1] with length 0

goroutine 23 [running]:
golang.org/x/tools/internal/imports.(*ModuleResolver).scanDirForPackage(0xc000052780, 0xc0001cd1e0, 0x16, 0x4, 0xc000408480, 0x4b, 0x0, 0x0, 0x0, 0x0, ...)
    /home/tendervittles/go/pkg/mod/golang.org/x/tools@v0.0.0-20190830223141-573d9926052a/internal/imports/mod.go:400 +0x74f
golang.org/x/tools/internal/imports.(*ModuleResolver).scan.func2(0xc0001cd1e0, 0x16, 0x4, 0xc000408480, 0x4b)
    /home/tendervittles/go/pkg/mod/golang.org/x/tools@v0.0.0-20190830223141-573d9926052a/internal/imports/mod.go:296 +0x141
golang.org/x/tools/internal/gopathwalk.(*walker).walk(0xc0000a01e0, 0xc000408480, 0x58, 0x0, 0xc000408480, 0x58)
    /home/tendervittles/go/pkg/mod/golang.org/x/tools@v0.0.0-20190830223141-573d9926052a/internal/gopathwalk/walk.go:193 +0xf3
golang.org/x/tools/internal/fastwalk.(*walker).onDirEnt(0xc000581200, 0xc000438000, 0x4b, 0xc0003195d0, 0xc, 0x0, 0x0, 0xc000167de0)
    /home/tendervittles/go/pkg/mod/golang.org/x/tools@v0.0.0-20190830223141-573d9926052a/internal/fastwalk/fastwalk.go:168 +0xbb
golang.org/x/tools/internal/fastwalk.readDir(0xc000438000, 0x4b, 0xc000169e50, 0x0, 0x0)
    /home/tendervittles/go/pkg/mod/golang.org/x/tools@v0.0.0-20190830223141-573d9926052a/internal/fastwalk/fastwalk_unix.go:68 +0x228
golang.org/x/tools/internal/fastwalk.(*walker).walk(0xc000581200, 0xc000438000, 0x4b, 0x1, 0x1, 0x0)
    /home/tendervittles/go/pkg/mod/golang.org/x/tools@v0.0.0-20190830223141-573d9926052a/internal/fastwalk/fastwalk.go:195 +0x6a
golang.org/x/tools/internal/fastwalk.(*walker).doWork(0xc000581200, 0xc0003f64b0)
    /home/tendervittles/go/pkg/mod/golang.org/x/tools@v0.0.0-20190830223141-573d9926052a/internal/fastwalk/fastwalk.go:134 +0x175
created by golang.org/x/tools/internal/fastwalk.Walk
    /home/tendervittles/go/pkg/mod/golang.org/x/tools@v0.0.0-20190830223141-573d9926052a/internal/fastwalk/fastwalk.go:81 +0x248

[tendervittles]

pilot error

[heschi]

I'd like to fix the crash anyway. What was the mistake, out of curiosity? Pointed GOPATH at something that wasn't a GOPATH?

cc @suzmue as an FYI, I'll fix it though.

[tendervittles]

@heschik

I have a go:generate that now needs to reference stuff under github/foo/bar@version.

To reduce the number of things to touch when I update that module, I added a build step to create the link bar under github/foo that pointed to the right github/foo/bar@version.

It looks like the bar lacking @version was unexpected.

I know the proper thing to do is to run go mod vendor and then reference the vendor path in my go:generate, but I liked the idea of purging vendor entirely.

[gopherbot]

Change https://golang.org/cl/193268 mentions this issue: internal/imports: ignore invalid mod cache entries