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: interface conversion: ir.Node is *ir.Name, not *ir.InstExpr #50264

csgura opened this issue Dec 20, 2021 · 4 comments


Copy link

@csgura csgura commented Dec 20, 2021

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

$ go version
go version devel go1.18-87b2a548 Sun Dec 19 20:16:45 2021 +0000 darwin/amd64

Does this issue reproduce with the latest release?


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

Gotip playground

What did you do?

What did you expect to see?

No error

What did you see instead?

# gotptest
panic: interface conversion: ir.Node is *ir.Name, not *ir.InstExpr

goroutine 1 [running]:
cmd/compile/internal/noder.(*genInst).getDictionarySym(0x138ee00, 0xc00042edd0, {0xc0004c2550, 0x1, 0x1}, 0x0)
	/usr/local/go/src/cmd/compile/internal/noder/stencil.go:1632 +0xf66
cmd/compile/internal/noder.(*genInst).getDictionaryValue(0x0?, {0x4b51b8?, 0xc0?}, 0x0?, {0xc0004c2550?, 0xc0004b5098?, 0x8?}, 0xf8?)
	/usr/local/go/src/cmd/compile/internal/noder/stencil.go:1755 +0x39
cmd/compile/internal/noder.(*genInst).getDictOrSubdict(0x138ee00?, 0xc000650d20?, {0xe92618?, 0xc000662510?}, 0x40?, {0xc0004c2550, 0x1, 0x1}, 0xe4?)
	/usr/local/go/src/cmd/compile/internal/noder/stencil.go:626 +0xdc
cmd/compile/internal/noder.(*genInst).scanForGenCalls.func1({0xe92618, 0xc000662510?})
	/usr/local/go/src/cmd/compile/internal/noder/stencil.go:177 +0x32f
cmd/compile/internal/ir.Visit.func1({0xe92618, 0xc000662510})
	/usr/local/go/src/cmd/compile/internal/ir/visit.go:105 +0x30
cmd/compile/internal/ir.(*StructKeyExpr).doChildren(0xe947b0?, 0xc00066f180?)
	/usr/local/go/src/cmd/compile/internal/ir/node_gen.go:1264 +0x53
cmd/compile/internal/ir.Visit.func1({0xe947b0, 0xc00066f180})
	/usr/local/go/src/cmd/compile/internal/ir/visit.go:106 +0x57
cmd/compile/internal/ir.(*CompLitExpr).doChildren(0xc000605b80, 0xc0004c4e40)
	/usr/local/go/src/cmd/compile/internal/ir/node_gen.go:392 +0x107
cmd/compile/internal/ir.Visit.func1({0xe92a00, 0xc000605b80})
	/usr/local/go/src/cmd/compile/internal/ir/visit.go:106 +0x57
cmd/compile/internal/ir.(*ReturnStmt).doChildren(0xe94170?, 0xc0004c4e40)
	/usr/local/go/src/cmd/compile/internal/ir/node_gen.go:1049 +0x8c
cmd/compile/internal/ir.Visit.func1({0xe94170, 0xc00066eff0})
	/usr/local/go/src/cmd/compile/internal/ir/visit.go:106 +0x57
cmd/compile/internal/ir.(*Func).doChildren(0xe92f78?, 0xc0004c4e40?)
	/usr/local/go/src/cmd/compile/internal/ir/func.go:152 +0x6e
cmd/compile/internal/ir.Visit.func1({0xe92f78, 0xc00065e420})
	/usr/local/go/src/cmd/compile/internal/ir/visit.go:106 +0x57
cmd/compile/internal/ir.Visit({0xe92f78, 0xc00065e420}, 0xc0004c1f00)
	/usr/local/go/src/cmd/compile/internal/ir/visit.go:108 +0xb8
cmd/compile/internal/noder.(*genInst).scanForGenCalls(0x138ee00, {0xe92f78, 0xc00065e420})
	/usr/local/go/src/cmd/compile/internal/noder/stencil.go:158 +0x1f0
cmd/compile/internal/noder.(*genInst).buildInstantiations(0x138ee00, 0x1)
	/usr/local/go/src/cmd/compile/internal/noder/stencil.go:73 +0x85
cmd/compile/internal/noder.(*irgen).generate(0xc0000fe240, {0xc0000ac448, 0x1, 0x203000?})
	/usr/local/go/src/cmd/compile/internal/noder/irgen.go:320 +0x3db
cmd/compile/internal/noder.check2({0xc0000ac448, 0x1, 0x1})
	/usr/local/go/src/cmd/compile/internal/noder/irgen.go:92 +0x16d
cmd/compile/internal/noder.LoadPackage({0xc0000b2100, 0x1, 0x0?})
	/usr/local/go/src/cmd/compile/internal/noder/noder.go:90 +0x335
	/usr/local/go/src/cmd/compile/internal/gc/main.go:191 +0xb13
	/usr/local/go/src/cmd/compile/main.go:55 +0xdd

If I remove these line, the error goes away

	v := option.Some(hello{})
	_ = v
Copy link

@danscales danscales commented Dec 20, 2021

I'll investigate this later today or tomorrow.

@ianlancetaylor ianlancetaylor added the NeedsInvestigation label Dec 20, 2021
@ianlancetaylor ianlancetaylor added this to the Go1.18 milestone Dec 20, 2021
Copy link

@ianlancetaylor ianlancetaylor commented Dec 20, 2021

Here is a standalone file that appears to create the same compiler crash.

package main

type hello struct{}

func main() {
	_ = Some(hello{})
	res := Applicative2(func(a int, b int) int {
		return 0
	_ = res

type NoneType[T any] struct{}

func (r NoneType[T]) Recover() any {
	return nil

type Func2[A1, A2, R any] func(a1 A1, a2 A2) R

func Some[T any](v T) any {
	return NoneType[T]{}.Recover()

type Nil struct{}

type ApplicativeFunctor2[H, HT, A1, A2, R any] struct {
	h  any

func Applicative2[A1, A2, R any](fn Func2[A1, A2, R]) ApplicativeFunctor2[Nil, Nil, A1, A2, R] {
	return ApplicativeFunctor2[Nil, Nil, A1, A2, R]{Some(Nil{})}

@danscales danscales self-assigned this Dec 21, 2021
Copy link

@danscales danscales commented Dec 21, 2021

Thanks, @csgura for the issue, and @ianlancetaylor for the simplified example!

I understand the issue and have a fix, but will work some more to make sure it is the cleanest fix.

Copy link

@gopherbot gopherbot commented Dec 21, 2021

Change mentions this issue: cmd/compile: save selector/inst info for generic method/function calls

jproberts pushed a commit to jproberts/go that referenced this issue Jun 21, 2022
In the dict info, we need to save the SelectorExpr of a generic method
call when making its sub-dictionary entry. The generic method call will
eventually be transformed into a function call on the method shape
instantiation, so we may not always have the selector info available
when we need it to create a dictionary. We use this SelectorExpr as
needed if the relevant call node has already been transformed.

Similarly, we save the InstExpr of generic function calls, since the
InstExpr will be dropped when the function call is transformed to a call
to a shape instantiation. We use this InstExpr if the relevant function
call has already been transformed.

Added an extra generic function Some2 and a call to it from Some that
exercises the generic function case. The existing test already tests the
method call case.

Fixes golang#50264

Change-Id: I2c7c7d79a8e33ca36a5e88e64e913c57500c97f9
Reviewed-by: Keith Randall <>
Trust: Dan Scales <>
Run-TryBot: Dan Scales <>
TryBot-Result: Gopher Robot <>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

4 participants