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: internal compiler error: weird package in name: .dict0 => .dict0 from "", not "test/p" #52117

Closed
zhuah opened this issue Apr 2, 2022 · 15 comments
Labels
NeedsFix

Comments

@zhuah
Copy link

@zhuah zhuah commented Apr 2, 2022

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

@mengzhuo mengzhuo commented Apr 2, 2022

Sounds like we should reopen #51423 ?

@hopehook
Copy link
Contributor

@hopehook hopehook commented Apr 2, 2022

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

@mengzhuo mengzhuo commented Apr 2, 2022

cc @cuonglm @randall77 per original CL

@zhuah
Copy link
Author

@zhuah zhuah commented Apr 2, 2022

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

@hopehook hopehook commented Apr 2, 2022

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 cuonglm added the NeedsInvestigation label Apr 2, 2022
@cuonglm
Copy link
Member

@cuonglm cuonglm commented Apr 2, 2022

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
Copy link

@gopherbot gopherbot commented Apr 5, 2022

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

@cuonglm
Copy link
Member

@cuonglm cuonglm commented Apr 5, 2022

Should we backport this? @randall77 @mdempsky

@mdempsky
Copy link
Member

@mdempsky mdempsky commented Apr 5, 2022

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
Copy link
Member

@cuonglm cuonglm commented Apr 6, 2022

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
Copy link
Author

@zhuah zhuah commented Apr 11, 2022

@cuonglm will this be fixed in 1.18.1?

@cuonglm
Copy link
Member

@cuonglm cuonglm commented Apr 26, 2022

@cuonglm will this be fixed in 1.18.1?

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

@cuonglm
Copy link
Member

@cuonglm cuonglm commented Apr 28, 2022

@gopherbot please backport this to 1.18

@gopherbot
Copy link

@gopherbot gopherbot commented Apr 28, 2022

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
Copy link

@gopherbot gopherbot commented Apr 29, 2022

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

gopherbot pushed a commit that referenced this issue May 2, 2022
This CL:

1. extracts typecheck.LookupNum into a method on *types.Pkg, so that
it can be used with any package, not just types.LocalPkg,

2. adds a new helper function closureSym to generate symbols in the
appropriate package as needed within stencil.go, and

3. updates the existing typecheck.LookupNum+Name.SetSym code to call
closureSym instead.

No functional change (so no need to backport to Go 1.18), but a little
cleaner, and avoids polluting types.LocalPkg.Syms with symbols that we
won't end up using.

Updates #52117.

Change-Id: Ifc8a3b76a37c830125e9d494530d1f5b2e3e3e2a
Reviewed-on: https://go-review.googlesource.com/c/go/+/403197
Reviewed-by: David Chase <drchase@google.com>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
@dmitshur dmitshur added NeedsFix and removed NeedsInvestigation labels May 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsFix
Projects
None yet
Development

No branches or pull requests

7 participants