The key point here is that the go binary being run has a GOROOT that does not match the clone of the repo in which it is running. The current behavior when running in a clone is to run the generate command in the original GOROOT, as can be seen by editing the clone and the original GOROOT in two different ways. I don't know what the right thing is to do here, but silently warping over to a different directory and running generate there cannot be our best choice. We could run generate in the current directory, or we could give an error.

CC @bcmills @jayconrod

I note in your go env output the line GOMOD="/home/eliben/eli/golang-go/src/go.mod".

That implies that you are working in a Go 1.13 GOROOT, but the go version output indicates that a Go 1.12 toolchain is being used. The Go 1.12 toolchain does not know how to work with the modules in a Go 1.13 GOROOT, so it's not surprising that this does not work.

What happens if you run go generate using a go toolchain built from a different GOROOT at head?

[I'm reproducing this on a different machine now, the original problem is still reproducible]

@bcmills

So I'm in ~/eli/golang-go/src/cmd/compile/internal/gc, where syntax.go has OFOOBAR added.

~/eli/golang-go/src/cmd/compile/internal/gc$ grep -C 4 OFOOBA syntax.go 
// Node ops.
const (
	OXXX Op = iota

	OFOOBAR

	// names
	ONAME    // var or func name
	ONONAME  // unnamed arg or return value: f(int, string) (int, error) { etc }

I built a new Go toolchain in a different directory, fresh from a clone taken a few minutes ago.

~/eli/golang-go/src/cmd/compile/internal/gc$ /usr/local/google/home/eliben/test/go-github/bin/go version
go version devel +41b9e99d5b Fri Jun 21 17:24:29 2019 +0000 linux/amd64

GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/usr/local/google/home/eliben/.cache/go-build"
GOENV="/usr/local/google/home/eliben/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/usr/local/google/home/eliben/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org"
GOROOT="/usr/lib/google-golang"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/google-golang/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/usr/local/google/home/eliben/eli/golang-go/src/cmd/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-build472372589=/tmp/go-build -gno-record-gcc-switches"

Running go generate with this toolchain, without modifying GOROOT:

~/eli/golang-go/src/cmd/compile/internal/gc$ /usr/local/google/home/eliben/test/go-github/bin/go generate syntax.go 
~/eli/golang-go/src/cmd/compile/internal/gc$ grep FOOBA op_string.go 

No luck.

@bcmills I would expect that it's exactly the same problem: confusion between the current GOROOT and the toolchain's GOROOT. But we can open a separate issue for it if you prefer.

It may well have the same root cause, but I prefer to have an issue for each symptom — that way I won't add a test for one symptom and forget to verify that it fixes the others.