cmd/compile: internal compiler error: invalid memory address or nil pointer dereference

[virtuald]

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

$ go version
go version devel go1.18-eaf0405 Wed Feb 16 21:34:51 2022 +0000 darwin/amd64

Does this issue reproduce with the latest release?

Yes

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

N/A

What did you do?

https://go.dev/play/p/V4-OtYakAMj?v=gotip

What did you expect to see?

Some error. Was trying to make a testcase for an inference bug.

What did you see instead?

./prog.go:23:11: internal compiler error: panic: runtime error: invalid memory address or nil pointer dereference

[virtuald]

https://go.dev/play/p/m_EXRkYORl-?v=gotip is similar, but I think it's slightly simpler, but also weirder?

At a glance, this second version seems mildly similar to #51219, maybe the fix for it at https://go.dev/cl/386335 applies here (cc @danscales)? It's a bit late though, so I haven't looked into how I could try out that CL directly.

[karitham]

I made a simpler one, which applies to my code in #51219 too, I'm pretty sure it's related so putting it there

https://go.dev/play/p/SI6WD_aSX8I?v=gotip

This probably shouldn't compile, but the compiler shouldn't panic

(Also tried with the CL, I'm not so sure it's the same issue)

Edit: Made another issue, unsure it's actually related to this one, #51236

[danscales]

#51219 is related to importing a highly recursive type, so the two failures in this issue are completely separate from that. The two cases appear to be distinct.

[danscales]

I made a simpler one, which applies to my code in #51219 too, I'm pretty sure it's related so putting it there

https://go.dev/play/p/SI6WD_aSX8I?v=gotip

This probably shouldn't compile, but the compiler shouldn't panic

(Also tried with the CL, I'm not so sure it's the same issue)

Edit: Made another issue, unsure it's actually related to this one, #51236

This example is a separate issue from the main one here, and it looks like it is the same as #51236 . So, let's make #51236 the main issue for handling this case (where the error message is something like: "internal compiler error: found illegal assignment main.Foo.UnmarshalJSON.T -> SLICE-[]byte;"

[dr2chase]

So I am looking at this, and where I have gotten thus far is that things go bad like so. I do not know why they go bad, only that the result type for the function-typed c.makeFn is nil.

package main

type RC[RG any] interface {
	~[]RG
}

type Fn[RCT RC[RG], RG any] func(RCT)

type F[RCT RC[RG], RG any] interface {
	Fn() Fn[RCT]
}

type concreteF[RCT RC[RG], RG any] struct {
	makeFn func() Fn[RCT]
}

func (c *concreteF[RCT, RG]) Fn() Fn[RCT] { // (2) tries to markInlBody this method of the type in (1)
	return c.makeFn() // (3) is c.makeFn's type fully instantiated?
	// (type is "func() Fn[RCT]" )
	// (4) In the compiler the result type is a struct, one field per result.
        //     There should be one field (a *types.Field), and it should have type Fn[RCT].
        //     however the *types.Field has a nil type; its non-zero/nil attributes are:
	//        flags types.bitset8 = 2
	//        Pos src.XPos = {index: 2, lico: 57600} 
	//        Offset int64 = -1000000000 
}

func NewConcrete[RCT RC[RG], RG any](Rc RCT) F[RCT] {
	return &concreteF[RCT]{ // (1) tries to markInlBody this type
		makeFn: nil,
	}
}

func main() {}

[mpx]

go version devel +c9fe126c8b Mon Feb 21 21:28:40 2022 +0000 linux/amd64

I suspect this much simpler test case is hitting the same bug (should not compile):

package boom

type Foo[T any, PT *T] struct{}

func (f *Foo[T]) boom() {}

..at least, the call chain is more or less the same compared to @dr2chase's example:

[..]
panic({0xcaba20, 0x1311df0})
        src/runtime/panic.go:838 +0x207
cmd/compile/internal/types.(*Type).IsImplicit(0xc000648690?)
        src/cmd/compile/internal/types/type.go:1907 +0x18
cmd/compile/internal/typecheck.(*iexporter).doDecl(0xc00063c000, 0xc00041a0d0)
        src/cmd/compile/internal/typecheck/iexport.go:568 +0x38d 
cmd/compile/internal/typecheck.WriteExports({0xe93080, 0xc00061a1b0}, 0x1)
        src/cmd/compile/internal/typecheck/iexport.go:334 +0x2f0
cmd/compile/internal/noder.WriteExports(0xc000628010)
        src/cmd/compile/internal/noder/export.go:40 +0x7a
cmd/compile/internal/gc.dumpCompilerObj(0xc000628010?)
        src/cmd/compile/internal/gc/obj.go:107 +0x28
cmd/compile/internal/gc.dumpobj1({0x7fff5b4cc9ce, 0x23}, 0x3)
        src/cmd/compile/internal/gc/obj.go:63 +0x17b
cmd/compile/internal/gc.dumpobj()
        src/cmd/compile/internal/gc/obj.go:44 +0x36
cmd/compile/internal/gc.Main(0xd52330)
        src/cmd/compile/internal/gc/main.go:330 +0x11bc
main.main()
        src/cmd/compile/main.go:55 +0xdd

[danscales]

@mpx I moved your case to a new issue - it is distinct. Thanks for providing it!

[danscales]

@griesemer @findleyr The original test case in this issue (see top issue description, https://go.dev/play/p/V4-OtYakAMj?v=gotip) seems to be a types2 bug (fairly unusual case).

It seems like it is probably happening because the type inference that is needed at line 14 is somewhat happening (so there is no typechecker error), but not completely happening, so types2 is returning a nil type to the compiler.

What's happening is that when we are noding the c.makeFn() call at line 18, the type of that call node is being returned as invalid. Here's some output from dlv from line 31 of cmd/compile/internal/noder/expr.go:

(dlv) p expr
cmd/compile/internal/syntax.Expr(*cmd/compile/internal/syntax.CallExpr) *{
        Fun: cmd/compile/internal/syntax.Expr(*cmd/compile/internal/syntax.SelectorExpr) *{
                X: cmd/compile/internal/syntax.Expr(*cmd/compile/internal/syntax.Name) ...,
                Sel: *(*"cmd/compile/internal/syntax.Name")(0xc00041e240),
                expr: (*"cmd/compile/internal/syntax.expr")(0xc0003e9368),},
        ArgList: []cmd/compile/internal/syntax.Expr len: 0, cap: 0, nil,
        HasDots: false,
        expr: cmd/compile/internal/syntax.expr {
                node: (*"cmd/compile/internal/syntax.node")(0xc000119a70),},}
(dlv) p expr.Fun
cmd/compile/internal/syntax.Expr(*cmd/compile/internal/syntax.SelectorExpr) *{
        X: cmd/compile/internal/syntax.Expr(*cmd/compile/internal/syntax.Name) *{
                Value: "c",
                expr: (*"cmd/compile/internal/syntax.expr")(0xc00041e230),},
        Sel: *cmd/compile/internal/syntax.Name {
                Value: "makeFn",
                expr: (*"cmd/compile/internal/syntax.expr")(0xc00041e250),},
        expr: cmd/compile/internal/syntax.expr {
                node: (*"cmd/compile/internal/syntax.node")(0xc0003e9368),},}
(dlv) p typ
cmd/compile/internal/types2.Type(*cmd/compile/internal/types2.Basic) *{
        kind: Invalid (0),
        info: 0,
        name: "invalid type",}
(dlv)

This invalid type turns into a nil type, which causes the compiler crash later on.

The entire program compiles and runs (since we get the correct valid type for the call) if we change line 14 from:

type concreteF[RCT RC[RG], RG any] struct {
	makeFn func() Fn[RCT]
}

to

type concreteF[RCT RC[RG], RG any] struct {
	makeFn func() Fn[RCT, RG]
}

(I.e. add in the RG typeparam so type inference doesn't need to figure it out).