Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: running go generate with go tool with different GOROOT fails #32724

Open
eliben opened this issue Jun 21, 2019 · 9 comments
Open

cmd/go: running go generate with go tool with different GOROOT fails #32724

eliben opened this issue Jun 21, 2019 · 9 comments

Comments

@eliben
Copy link
Member

@eliben eliben commented Jun 21, 2019

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

$ go version
go version go1.12 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
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/eliben/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/eliben/eli/go"
GOPROXY="https://proxy.golang.org"
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/eliben/eli/golang-go/src/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-build618171788=/tmp/go-build -gno-record-gcc-switches"

What did you do?

  1. Created a fresh clone of the Go repository.
  2. $ cd src/cmd/compile/internal/gc
  3. Edit syntax.go to add a new AST node type OFOOBAR
$ grep -C 4 OFOOBAR 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 }
  1. Ran go generate
$ go generate 
stringer: writing output: open class_string.go: permission denied
/usr/local/go/src/cmd/compile/internal/gc/go.go:43: running "stringer": exit status 1

Expected op_string.go to be updated with the new node type.

Also ran:

$ go generate syntax.go

No errors, but the generated op_string.go does not have the new node type.

What did you expect to see?

Expected the new node type to appear in op_string.go after running go generate

eliben added a commit to eliben/go that referenced this issue Jun 21, 2019
@ianlancetaylor ianlancetaylor changed the title Running go generate within cmd/compile/internal/gc doesn't work generate the right code cmd/go: running go generate with go tool with different GOROOT fails Jun 21, 2019
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Jun 21, 2019

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

Loading

@bcmills
Copy link
Member

@bcmills bcmills commented Jun 21, 2019

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?

Loading

@eliben
Copy link
Member Author

@eliben eliben commented Jun 21, 2019

[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
/usr/local/google/home/eliben/test/go-github/bin/go env Output
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.

Loading

@gertcuykens

This comment was marked as off-topic.

@bcmills

This comment was marked as off-topic.

@gertcuykens

This comment was marked as off-topic.

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Jul 16, 2019

@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.

Loading

@bcmills
Copy link
Member

@bcmills bcmills commented Jul 16, 2019

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.

Loading

@gertcuykens

This comment has been hidden.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants