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

Closed
csgura opened this issue Dec 20, 2021 · 4 comments
Closed
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@csgura
Copy link

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?

Yes.

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

Gotip playground

What did you do?

https://gotipplay.golang.org/p/cYYbFhofOog

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.DoChildren(...)
	/usr/local/go/src/cmd/compile/internal/ir/visit.go:94
cmd/compile/internal/ir.Visit.func1({0xe947b0, 0xc00066f180})
	/usr/local/go/src/cmd/compile/internal/ir/visit.go:106 +0x57
cmd/compile/internal/ir.doNodes(...)
	/usr/local/go/src/cmd/compile/internal/ir/node_gen.go:1512
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.DoChildren(...)
	/usr/local/go/src/cmd/compile/internal/ir/visit.go:94
cmd/compile/internal/ir.Visit.func1({0xe92a00, 0xc000605b80})
	/usr/local/go/src/cmd/compile/internal/ir/visit.go:106 +0x57
cmd/compile/internal/ir.doNodes(...)
	/usr/local/go/src/cmd/compile/internal/ir/node_gen.go:1512
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.DoChildren(...)
	/usr/local/go/src/cmd/compile/internal/ir/visit.go:94
cmd/compile/internal/ir.Visit.func1({0xe94170, 0xc00066eff0})
	/usr/local/go/src/cmd/compile/internal/ir/visit.go:106 +0x57
cmd/compile/internal/ir.doNodes(...)
	/usr/local/go/src/cmd/compile/internal/ir/node_gen.go:1512
cmd/compile/internal/ir.(*Func).doChildren(0xe92f78?, 0xc0004c4e40?)
	/usr/local/go/src/cmd/compile/internal/ir/func.go:152 +0x6e
cmd/compile/internal/ir.DoChildren(...)
	/usr/local/go/src/cmd/compile/internal/ir/visit.go:94
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.BuildInstantiations(...)
	/usr/local/go/src/cmd/compile/internal/noder/stencil.go:47
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
cmd/compile/internal/gc.Main(0xd4bb90)
	/usr/local/go/src/cmd/compile/internal/gc/main.go:191 +0xb13
main.main()
	/usr/local/go/src/cmd/compile/main.go:55 +0xdd

If I remove these line, the error goes away

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

I'll investigate this later today or tomorrow.

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

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
@danscales
Copy link
Contributor

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.

@gopherbot
Copy link

Change https://golang.org/cl/373754 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-on: https://go-review.googlesource.com/c/go/+/373754
Reviewed-by: Keith Randall <khr@golang.org>
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
@golang golang locked and limited conversation to collaborators Jun 22, 2023
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

4 participants