cmd/go: 'go get' with -overlay can incorrectly run in GOPATH mode

[jayconrod]

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

$ go version
go version go1.16.5 darwin/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="auto"
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/jayconrod/Library/Caches/go-build"
GOENV="/Users/jayconrod/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/jayconrod/Code/test/gopath/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/jayconrod/Code/test/gopath"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/opt/go/installed"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/opt/go/installed/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.16.5"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/rq/x0692kqj6ml8cvrhcqh5bswc008xj1/T/go-build1536558447=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

export GOPATH=$(pwd)/gopath
export GO111MODULE=auto
go get -d -overlay=overlay.json rsc.io/quote

-- overlay.json --
{
  "Replace": {
    "go.mod": "go-overlay.mod"
  }
}
-- go-overlay.mod --
module test

go 1.16

What did you expect to see?

go get should run in module-aware mode because GO111MODULE is auto, and a go.mod file is present in the overlay. It should report an error that go.mod in the overlay cannot be modified.

What did you see instead?

go get gets confused about whether it's in module-aware mode and panics.

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x50 pc=0x143711c]

goroutine 1 [running]:
cmd/go/internal/modload.Lookup(0x0, 0x0, 0x0, 0x7ffeefbff8c8, 0xc, 0x19db7a8, 0x985c67ecba681c12, 0x0, 0xc0000bf608, 0x100f7b8, ...)
	/usr/local/go/src/cmd/go/internal/modload/load.go:647 +0x5c
cmd/go/internal/load.loadPackageData.func1(0x19db7a0, 0x1615ee0)
	/usr/local/go/src/cmd/go/internal/load/pkg.go:808 +0x285
cmd/go/internal/par.(*Cache).Do(0x19db7a0, 0x1615ee0, 0xc00008e1e0, 0xc0000bf878, 0xffffffffffffffff, 0x20300000000000)
	/usr/local/go/src/cmd/go/internal/par/work.go:128 +0xec
cmd/go/internal/load.loadPackageData(0x7ffeefbff8c8, 0xc, 0x0, 0x0, 0xc00002e004, 0x1a, 0x0, 0x0, 0x0, 0x0, ...)
	/usr/local/go/src/cmd/go/internal/load/pkg.go:802 +0x265
cmd/go/internal/load.loadImport(0x1721cc8, 0xc0000a4008, 0x0, 0x7ffeefbff8c8, 0xc, 0xc00002e004, 0x1a, 0x0, 0xc0000bfdd8, 0x0, ...)
	/usr/local/go/src/cmd/go/internal/load/pkg.go:668 +0xeb
cmd/go/internal/load.LoadImport(...)
	/usr/local/go/src/cmd/go/internal/load/pkg.go:653
cmd/go/internal/get.download.func1(0x7ffeefbff8c8, 0xc, 0x0, 0x58)
	/usr/local/go/src/cmd/go/internal/get/get.go:258 +0x137
cmd/go/internal/get.download(0x7ffeefbff8c8, 0xc, 0x0, 0xc0000bfdd8, 0x0)
	/usr/local/go/src/cmd/go/internal/get/get.go:263 +0xbc
cmd/go/internal/get.runGet(0x1721cc8, 0xc0000a4000, 0x19d0e00, 0xc00008e090, 0x1, 0x1)
	/usr/local/go/src/cmd/go/internal/get/get.go:170 +0x1a5
main.main()
	/usr/local/go/src/cmd/go/main.go:195 +0x70c

[jayconrod]

This happens because internally, there are two distinct go get subcommands. When GO111MODULE is auto, the go command looks for a go.mod to decide which to use. This happens before flags are parsed and the overlay is initialized though.

cc @matloob @bcmills. This is pretty low priority though: I don't expect anyone to run into this in practice.