cmd/go2go: importing k8s package makes compilation hang

[imjasonh]

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

$ go version
go version devel +9cd52cf2a9 Tue Apr 13 00:32:27 2021 +0000 linux/amd64

Does this issue reproduce with the latest release?

n/a, not released

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/imjasonh/.cache/go-build"
GOENV="/home/imjasonh/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/imjasonh/gopath/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/imjasonh/gopath:/google/gopath"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/imjasonh/goroot"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/imjasonh/goroot/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="devel +9cd52cf2a9 Tue Apr 13 00:32:27 2021 +0000"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/imjasonh/git/client-go2/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-build7496520=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I ran main.go2:

package main

import "fmt"

func main() {
  fmt.Println("yay")
}

$ time ~/goroot/bin/go tool go2go run main.go2
yay

real	0m0.256s
user	0m0.167s
sys	0m0.111s

(sometimes longer if it actually has to compile, maybe 2s)

Then I added an import:

package main

import (
  "fmt"
  "k8s.io/client-go/dynamic"
)

func main() {
  fmt.Println("yay")
}

$ time ~/goroot/bin/go tool go2go run main.go2
... hangs ...
... give up, ctrl+c ...
real	12m43.152s
user	15m11.975s
sys	0m39.563s

If I add a different import instead (github.com/imjasonh/csvstruct), it compiles and tells me the import was unused, much more quickly:

/tmp/go2go-run2270470034/main.go2:5:1: "github.com/imjasonh/csvstruct" imported but not used

real	0m0.197s
user	0m0.161s
sys	0m0.106s

What did you expect to see?

I expected to see a relatively prompt compilation error indicating the import was unused.

What did you see instead?

Indefinite hanging, giving up after 12 minutes.

Is there something unusual about the k8s import that causes this to blow up?

[mknyszek]

Given that the go2go tool is largely experimental, and that the generics proposal has been accepted, I don't know how much is going to be done about this. I don't think it was ever intended to support a project as large and diverse as Kubernetes.

Nonetheless, CC @ianlancetaylor @griesemer in case they have anything to say about it.

[imjasonh]

Thanks @mknyszek, I definitely understand if go2go as an experimental tool isn't intended to support importing such large/complex packages.

Is there a better way I should be trying to experiment with "real" generics support in Go with Kubernetes?

[griesemer]

The latest development is happening on the dev.typeparams branch - this branch is expected to become the master branch for the Go1.18 release.

You could check out that branch, build Go from source, and then use that compiler, by calling: go run -gcflags=-G=3 main.go. The -G=3 flag enables the generics-aware type-checker and code generation.

We'd be very interested in any bugs/crashes that you might run into. Thanks.

[ianlancetaylor]

I haven't looked into this, but the go2go tool does a source code parse of every package, and makes no attempt whatsoever at doing so efficiently. The chances that it will work with a large existing body of code are small.

I'm going to close this issue because we aren't maintaining go2go any more. If someone wants to look into this and send a patch, I'll review it, but we aren't going to do anything ourselves. Sorry.

[imjasonh]

Thanks for that clarification, I'll work against the dev.typeparams branch and let you know how it goes.

Would it make sense to update the dev.go2go branch to document that it's unsupported, and to use dev.typeparams instead?

[ianlancetaylor]

To be clear, neither is supported.

But, yes, updating the go2go README makes sense at this point. Sent https://golang.org/cl/322192.

[gopherbot]

Change https://golang.org/cl/322192 mentions this issue: [dev.go2go] README: document that this branch is no longer maintained