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/compile: panic when using typeparams #46353

Closed
imjasonh opened this issue May 24, 2021 · 2 comments
Closed

cmd/compile: panic when using typeparams #46353

imjasonh opened this issue May 24, 2021 · 2 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@imjasonh
Copy link

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

$ go version
go version devel go1.17-5b1120fac7 Fri May 21 23:25:07 2021 +0000 darwin/amd64

Compiled from source from the dev.typeparams branch.

Does this issue reproduce with the latest release?

No; support for typeparams is not yet released

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

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/jasonhall/Library/Caches/go-build"
GOENV="/Users/jasonhall/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/jasonhall/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/jasonhall/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/Users/jasonhall/git/goroot"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/Users/jasonhall/git/goroot/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="devel go1.17-5b1120fac7 Fri May 21 23:25:07 2021 +0000"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/jasonhall/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 -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/bb/l0yfqc6d6kb5zm5f9ktyx0nw0000gn/T/go-build4116573109=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

I attempted to write a Go program using type params. This example is distilled from real-world code to attempt to isolate the bug.

package main

func main() {
        _ = New[*foo]()
}

type i interface { Foo() }
type foo struct {}
func (f *foo) Foo() {} // satisfy interface

func New[T i]() str[T] {
        return str[T]{}
}

type str[T i] struct {
        s string
}

(running with go run -gcflags=-G=3 test.go as recommended in #46346)

What did you expect to see?

I expected to see a successfully compiled program that exits ~immediately.

What did you see instead?

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

goroutine 1 [running]:
cmd/compile/internal/ir.(*Name).TypeDefn(0x18da9c0)
	/Users/jasonhall/git/goroot/src/cmd/compile/internal/ir/name.go:146 +0x22
cmd/compile/internal/types.findTypeLoop(0xc0000ad0a0, 0xc00011d540)
	/Users/jasonhall/git/goroot/src/cmd/compile/internal/types/size.go:239 +0x290
cmd/compile/internal/types.reportTypeLoop(0xc0000ad0a0)
	/Users/jasonhall/git/goroot/src/cmd/compile/internal/types/size.go:277 +0x65
cmd/compile/internal/types.CalcSize(0xc0000ad0a0)
	/Users/jasonhall/git/goroot/src/cmd/compile/internal/types/size.go:432 +0x68b
cmd/compile/internal/walk.convas(0xc0003d19f0, 0xc00011d810)
	/Users/jasonhall/git/goroot/src/cmd/compile/internal/walk/walk.go:96 +0x27b
cmd/compile/internal/walk.ascompatee(0x16, {0xc000094530, 0x0, 0x8}, {0xc000094540, 0x380bc90, 0xc0000c3218})
	/Users/jasonhall/git/goroot/src/cmd/compile/internal/walk/assign.go:372 +0x6e6
cmd/compile/internal/walk.walkAssignList(0xc00011dad8, 0xc000093680)
	/Users/jasonhall/git/goroot/src/cmd/compile/internal/walk/assign.go:146 +0x12f
cmd/compile/internal/walk.walkExpr1({0x1a4a760, 0xc000093680}, 0xc00011dad8)
	/Users/jasonhall/git/goroot/src/cmd/compile/internal/walk/expr.go:179 +0x2fc
cmd/compile/internal/walk.walkExpr({0x1a4a760, 0xc000093680}, 0xc00011dad8)
	/Users/jasonhall/git/goroot/src/cmd/compile/internal/walk/expr.go:55 +0x3a5
cmd/compile/internal/walk.walkStmt({0x1a4a760, 0xc000093680})
	/Users/jasonhall/git/goroot/src/cmd/compile/internal/walk/stmt.go:59 +0x57e
cmd/compile/internal/walk.walkStmtList({0xc0003e0b80, 0x6, 0xc000096420})
	/Users/jasonhall/git/goroot/src/cmd/compile/internal/walk/stmt.go:169 +0x5b
cmd/compile/internal/walk.Walk(0xc000096420)
	/Users/jasonhall/git/goroot/src/cmd/compile/internal/walk/walk.go:43 +0xef
cmd/compile/internal/gc.prepareFunc(0xc000096420)
	/Users/jasonhall/git/goroot/src/cmd/compile/internal/gc/compile.go:92 +0x6d
cmd/compile/internal/gc.enqueueFunc(0xc000096420)
	/Users/jasonhall/git/goroot/src/cmd/compile/internal/gc/compile.go:66 +0x2f7
cmd/compile/internal/gc.Main(0x1913c48)
	/Users/jasonhall/git/goroot/src/cmd/compile/internal/gc/main.go:281 +0xe05
main.main()
	/Users/jasonhall/git/goroot/src/cmd/compile/main.go:55 +0xdd

Perhaps interestingly, slight variations on the code seem to compile without issue. Any of these changes result in successful compilation:

  1. Removing the s string field from the str[T i] type.
  2. Bypassing the New method and calling _ = str[*foo]{} directly instead.
  3. Making foo implement i instead of *foo, and calling _ = New[foo]().

cc @ianlancetaylor @griesemer

@mknyszek mknyszek added this to the Go1.18 milestone May 24, 2021
@mknyszek mknyszek added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label May 24, 2021
@ianlancetaylor
Copy link
Contributor

Thanks. The type parameters work is under very active development by a number of people. I don't think it is useful at this time to file issues about problems using type parameters.

@imjasonh
Copy link
Author

imjasonh commented May 24, 2021 via email

@cespare cespare closed this as completed May 24, 2021
@golang golang locked and limited conversation to collaborators May 24, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

5 participants