cmd/compile: crash in make running generic code [1.18 backport]

[mier85]

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

go version go1.18 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

GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/mier85/.cache/go-build"
GOENV="/home/mier85/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/mier85/go/pkg/mod"
GONOPROXY=
GONOSUMDB=
GOOS="linux"
GOPATH="/home/mier85/go"
GOPRIVATE=
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.18"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
GOWORK=""
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-build2488678595=/tmp/go-build -gno-record-gcc-switches"

What did you do?

https://go.dev/play/p/ys1JxRrYwce

What did you expect to see?

=== RUN   TestRunner
=== RUN   TestRunner/#00
[]string{"blubb"}--- PASS: TestRunner (0.00s)
    --- PASS: TestRunner/#00 (0.00s)
PASS

What did you see instead?

=== RUN   TestRunner
=== RUN   TestRunner/#00
--- FAIL: TestRunner (0.00s)
    --- FAIL: TestRunner/#00 (0.00s)
panic: runtime error: makeslice: cap out of range [recovered]
	panic: runtime error: makeslice: cap out of range

goroutine 19 [running]:
testing.tRunner.func1.2({0x4bf6a0, 0x4f7f00})
	/usr/local/go-faketime/src/testing/testing.go:1389 +0x24e
testing.tRunner.func1()
	/usr/local/go-faketime/src/testing/testing.go:1392 +0x39f
panic({0x4bf6a0, 0x4f7f00})
	/usr/local/go-faketime/src/runtime/panic.go:838 +0x207
strconv.appendQuotedWith({0xc0000a2c98, 0x0, 0x45b5d9?}, {0x2e676e6974736574, 0x72656e6e755274}, 0x22, 0x85?, 0x50?)
	/usr/local/go-faketime/src/strconv/quote.go:35 +0x86
strconv.AppendQuote(...)
	/usr/local/go-faketime/src/strconv/quote.go:135
fmt.(*fmt).fmtQ(0xc0000a2c70, {0x2e676e6974736574, 0x4bba80?})
	/usr/local/go-faketime/src/fmt/format.go:457 +0xe8
fmt.(*pp).fmtString(0x4bba80?, {0x2e676e6974736574?, 0x0?}, 0x0?)
	/usr/local/go-faketime/src/fmt/print.go:441 +0x7b
fmt.(*pp).printValue(0xc0000a2c30, {0x4bba80?, 0x508561?, 0x0?}, 0x76, 0x1)
	/usr/local/go-faketime/src/fmt/print.go:757 +0xf32
fmt.(*pp).printValue(0xc0000a2c30, {0x4ba400?, 0xc0000ac0a8?, 0x4aba33?}, 0x76, 0x0)
	/usr/local/go-faketime/src/fmt/print.go:856 +0x1615
fmt.(*pp).printArg(0xc0000a2c30, {0x4ba400?, 0xc0000ac0a8}, 0x76)
	/usr/local/go-faketime/src/fmt/print.go:712 +0x74c
fmt.(*pp).doPrintf(0xc0000a2c30, {0x4d2be5, 0x3}, {0xc000093f08?, 0x1, 0x1})
	/usr/local/go-faketime/src/fmt/print.go:1026 +0x288
fmt.Fprintf({0x4f8308, 0xc0000b2008}, {0x4d2be5, 0x3}, {0xc000038708, 0x1, 0x1})
	/usr/local/go-faketime/src/fmt/print.go:204 +0x75
fmt.Printf(...)
	/usr/local/go-faketime/src/fmt/print.go:213
main.Fixture.Run(...)
	/tmp/sandbox3516507230/prog.go:34
testing.tRunner(0xc000083040, 0xc0000ac078)
	/usr/local/go-faketime/src/testing/testing.go:1439 +0x102
created by testing.(*T).Run
	/usr/local/go-faketime/src/testing/testing.go:1486 +0x35f

[ianlancetaylor]

This test works on tip, fails on Go 1.18 branch. A git bisect suggests that it was fixed by https://go.dev/cl/395594 which reverted https://go.dev/cl/378178. I'm not sure whether we should backport 395594 to the 1.18 branch.

CC @randall77

[ianlancetaylor]

Since this is fixed on tip, I'm marking this as a cherry pick candidate for 1.18.

[heschi]

cc @mdempsky @randall77

[toothrot]

Any updates on this issue? @randall77

[gopherbot]

Change https://go.dev/cl/411120 mentions this issue: [release-branch.go1.18] Revert "cmd/compile: stop interface conversions for generic method calls from allocating"

[cherrymui]

CL 395594 doesn't apply cleanly to the 1.18 branch, but the edit is small. I made https://go-review.googlesource.com/c/go/+/411120 , which does seem to fix the issue.

@randall77 what do you think? Should we backport the reverting CL? Thanks.

[cherrymui]

I think we are still unclear what the best fix it. Also, as we discussed in #53852 (comment) , we will stop backporting non-revert generics issues to 1.18, so we don't destabilize Go 1.18. Maybe we don't backport this one?

[dmitshur]

We've discussed this backport request. It was found that backporting individual CLs for generic fixes can cause destabilization and create new issues, so because of that risk we're not going to accept this backport candidate. This problem doesn't exist in Go 1.19 and future major Go releases.