cmd/compile: internal compiler error: weird package in name: .dict0 => .dict0 from "", not "test/p"

[zhuah]

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

$ go version
go version devel go1.19-f8e70fc9a6 Sat Apr 2 06:48:45 2022 +0000 darwin/amd64

Does this issue reproduce with the latest release?

Yes

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

go env Output

$ go env

What did you do?

go compiler panicked with generics code, i made a reproduce demo at https://go.dev/play/p/4sC7oDiNFJs

-- go.mod --
module test
-- p/a.go --
package p

func Compare[T int | uint](a, b T) int {
	return 0
}

type Slice[T int | uint] struct{}

func (l Slice[T]) Comparator() func(v1, v2 T) int {
	return Compare[T]
}
-- main.go --
package main

import "test/p"

func Test() {
	var _ p.Slice[uint]
}

the error logs:

<autogenerated>:1: internal compiler error: weird package in name: .dict0 => .dict0 from "", not "github.com/kita-ui/kita/view/b"

goroutine 1 [running]:
runtime/debug.Stack()
        /usr/local/Cellar/gotip/src/runtime/debug/stack.go:24 +0x65
cmd/compile/internal/base.FatalfAt({0x30121?, 0xc0?}, {0x1926387, 0x2f}, {0xc000425660, 0x4, 0x4})
        /usr/local/Cellar/gotip/src/cmd/compile/internal/base/print.go:227 +0x1d7
cmd/compile/internal/base.Fatalf(...)
        /usr/local/Cellar/gotip/src/cmd/compile/internal/base/print.go:196
cmd/compile/internal/typecheck.(*exportWriter).localIdent(0xc000094a10?, 0xc000409200?)
        /usr/local/Cellar/gotip/src/cmd/compile/internal/typecheck/iexport.go:2276 +0x287
cmd/compile/internal/typecheck.(*exportWriter).writeNames(0xc000094a10, {0xc000610000, 0x4, 0x18d8520?})
        /usr/local/Cellar/gotip/src/cmd/compile/internal/typecheck/iexport.go:1494 +0x78
cmd/compile/internal/typecheck.(*exportWriter).funcBody(0xc000094a10?, 0xc000414140)
        /usr/local/Cellar/gotip/src/cmd/compile/internal/typecheck/iexport.go:1503 +0x39
cmd/compile/internal/typecheck.(*iexporter).doInline(0xc00064a6e0, 0xc0003faf00)
        /usr/local/Cellar/gotip/src/cmd/compile/internal/typecheck/iexport.go:664 +0xca
cmd/compile/internal/typecheck.(*exportWriter).funcExt(0xc0000947e0, 0xc0003faf00)
        /usr/local/Cellar/gotip/src/cmd/compile/internal/typecheck/iexport.go:1442 +0x1cd
cmd/compile/internal/typecheck.(*iexporter).doDecl(0xc00064a6e0, 0xc0003faf00)
        /usr/local/Cellar/gotip/src/cmd/compile/internal/typecheck/iexport.go:536 +0x21d
cmd/compile/internal/typecheck.WriteExports({0x1a664e0, 0xc000092d80}, 0x1)
        /usr/local/Cellar/gotip/src/cmd/compile/internal/typecheck/iexport.go:334 +0x2fe
cmd/compile/internal/noder.WriteExports(0xc000069390)
        /usr/local/Cellar/gotip/src/cmd/compile/internal/noder/export.go:40 +0x7a
cmd/compile/internal/gc.dumpCompilerObj(0xc000069390?)
        /usr/local/Cellar/gotip/src/cmd/compile/internal/gc/obj.go:107 +0x28
cmd/compile/internal/gc.dumpobj1({0x7ffeefbff1b9, 0x50}, 0x3)
        /usr/local/Cellar/gotip/src/cmd/compile/internal/gc/obj.go:63 +0x17b
cmd/compile/internal/gc.dumpobj()
        /usr/local/Cellar/gotip/src/cmd/compile/internal/gc/obj.go:44 +0x36
cmd/compile/internal/gc.Main(0x1934110)
        /usr/local/Cellar/gotip/src/cmd/compile/internal/gc/main.go:321 +0x1176
main.main()
        /usr/local/Cellar/gotip/src/cmd/compile/main.go:55 +0xdd

this bug is similar with #51423, i have made a temporary workaround in my code by change return Compare[T] to return func(x, y int) int { return a.CompareInt[int](x,y) } before #51423 was fixed, and forgot to change it back after 1.18 released, today i remove this workaround and found that the bug still exists

What did you expect to see?

What did you see instead?

[mengzhuo]

Sounds like we should reopen #51423 ?

[hopehook]

I can not reproduce the problem of #51423, but this issue can be reproduced.

go version devel go1.19-532ef8e4e5 Fri Apr 1 11:40:03 2022 +0800 darwin/amd64

It seems that caused by the exported func name Test

[mengzhuo]

cc @cuonglm @randall77 per original CL

[zhuah]

@hopehook Yes, the test case is a bit different with previous one, and the original CL doesn't covers this new case.

It seems that caused by the exported func name Test

the Test function imports Comparator method defined on Slice[T] and that method causes this issue.

[hopehook]

I've found that if you use p.Slice[int] normally, it works fine, or if you don't export the Test function.

• use p.Slice[int] normally

package main

import (
	"fmt"
	"test/p"
)

func main() {
	Test()
}

func Test() {
	var x p.Slice[int]
	fmt.Println(x.Comparator()(1, 1))
}

• don't export the Test function

package main

import (
	"test/p"
)

func main() {
	test()
}

func test() {
	var _ p.Slice[int]
}

[cuonglm]

I'm AFK, but it seems to me this problem is different with #51423, which involves re-export closures signature.

The problem here seems to be about exporting inline-ed function body.

[gopherbot]

Change https://go.dev/cl/398474 mentions this issue: cmd/compile: set correct package for vars/params/results from nested instantiation

[cuonglm]

Should we backport this? @randall77 @mdempsky

[mdempsky]

Stepping back a bit, I'm surprised we're exporting post-stenciled functions. Do we actually make use of those today?

I assume there's code for reading in the generic version and applying stenciling based on type arguments, since we need to handle the case where we're instantiating with never before seen type arguments. Can we just always use that code?

[cuonglm]

Stepping back a bit, I'm surprised we're exporting post-stenciled functions. Do we actually make use of those today?

I think yes, so we don't need to be re-typechecked on import.

I assume there's code for reading in the generic version and applying stenciling based on type arguments, since we need to handle the case where we're instantiating with never before seen type arguments. Can we just always use that code?

Hmm, not sure that's the case for iimport.go today.

[zhuah]

@cuonglm will this be fixed in 1.18.1?

[cuonglm]

@cuonglm will this be fixed in 1.18.1?

I think yes, since when this is very similar to #51423

[cuonglm]

@gopherbot please backport this to 1.18

[gopherbot]

Backport issue(s) opened: #52606 (for 1.18).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases.

[gopherbot]

Change https://go.dev/cl/403197 mentions this issue: cmd/compile: simplify code from CL 398474