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: p.a => a from "test/p", not "" #51423

Closed
zhuah opened this issue Mar 2, 2022 · 12 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. release-blocker
Milestone

Comments

@zhuah
Copy link

zhuah commented Mar 2, 2022

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

$ go version
go version devel go1.19-6da16b6ad5 Tue Mar 1 23:49:01 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/F8oOkWnPvfG?v=gotip

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

type Comparator[T any] func(v1, v2 T) int

func CompareInt[T ~int](a, b T) int {
	if a < b {
		return -1
	}
	if a == b {
		return 0
	}
	return 1
}
-- main.go --
package main

import "test/p"

func Comparator() p.Comparator[int] {
	return p.CompareInt[int]
}

func main() {
	Comparator()(1, 2)
}

and the error logs:

# test
./main.go:6:11: internal compiler error: weird package in name: p.a => a from "test/p", not ""

goroutine 1 [running]:
runtime/debug.Stack()
	/usr/local/go/src/runtime/debug/stack.go:24 +0x65
cmd/compile/internal/base.FatalfAt({0x0?, 0x0?}, {0xd40041, 0x2f}, {0xc0000c3308, 0x4, 0x4})
	/usr/local/go/src/cmd/compile/internal/base/print.go:227 +0x1d7
cmd/compile/internal/base.Fatalf(...)
	/usr/local/go/src/cmd/compile/internal/base/print.go:196
cmd/compile/internal/typecheck.(*exportWriter).localIdent(0xc0003ed500?, 0xc0003c4870?)
	/usr/local/go/src/cmd/compile/internal/typecheck/iexport.go:2276 +0x287
cmd/compile/internal/typecheck.(*exportWriter).param(0x40a2f3?, 0xc0003c4a00)
	/usr/local/go/src/cmd/compile/internal/typecheck/iexport.go:1130 +0xac
cmd/compile/internal/typecheck.(*exportWriter).paramList(0xc0003ed500, {0xc00008ce70, 0x2, 0xb?})
	/usr/local/go/src/cmd/compile/internal/typecheck/iexport.go:1124 +0x50
cmd/compile/internal/typecheck.(*exportWriter).signature(0xc0003ed500, 0xc0003d8730?)
	/usr/local/go/src/cmd/compile/internal/typecheck/iexport.go:1097 +0x65
cmd/compile/internal/typecheck.(*exportWriter).expr(0xc0003ed500, {0xe945d0?, 0xc0003d8730?})
	/usr/local/go/src/cmd/compile/internal/typecheck/iexport.go:1841 +0x105
cmd/compile/internal/typecheck.(*exportWriter).expr(0xc0003ed500, {0xe948f0?, 0xc0003d86e0?})
	/usr/local/go/src/cmd/compile/internal/typecheck/iexport.go:2021 +0x110f
cmd/compile/internal/typecheck.(*exportWriter).exprList(0xc0003ed500, {0xc00008d210?, 0x1, 0xc000378770?})
	/usr/local/go/src/cmd/compile/internal/typecheck/iexport.go:1718 +0x76
cmd/compile/internal/typecheck.(*exportWriter).stmt(0xc0003ed500, {0xe95ed0, 0xc0003d8690})
	/usr/local/go/src/cmd/compile/internal/typecheck/iexport.go:1611 +0x91f
cmd/compile/internal/typecheck.(*exportWriter).node(0xc0004a3380?, {0xe95ed0, 0xc0003d8690})
	/usr/local/go/src/cmd/compile/internal/typecheck/iexport.go:1520 +0x65
cmd/compile/internal/typecheck.(*exportWriter).stmtList(0xc0003ed500, {0xc00008d1f0?, 0x1, 0xcefda0?})
	/usr/local/go/src/cmd/compile/internal/typecheck/iexport.go:1513 +0x76
cmd/compile/internal/typecheck.(*exportWriter).funcBody(0xc0003ed500?, 0xc0003b9080)
	/usr/local/go/src/cmd/compile/internal/typecheck/iexport.go:1508 +0x5b
cmd/compile/internal/typecheck.(*iexporter).doInline(0xc00031e6e0, 0xc0003c8680)
	/usr/local/go/src/cmd/compile/internal/typecheck/iexport.go:664 +0xc5
cmd/compile/internal/typecheck.(*exportWriter).funcExt(0xc0003ed3b0, 0xc0003c8680)
	/usr/local/go/src/cmd/compile/internal/typecheck/iexport.go:1445 +0x1cd
cmd/compile/internal/typecheck.(*iexporter).doDecl(0xc00031e6e0, 0xc0003c8680)
	/usr/local/go/src/cmd/compile/internal/typecheck/iexport.go:536 +0x215
cmd/compile/internal/typecheck.WriteExports({0xe8e7e0, 0xc0004a3170}, 0x1)
	/usr/local/go/src/cmd/compile/internal/typecheck/iexport.go:334 +0x2f0
cmd/compile/internal/noder.WriteExports(0xc0004a4430)
	/usr/local/go/src/cmd/compile/internal/noder/export.go:40 +0x7a
cmd/compile/internal/gc.dumpCompilerObj(0xc0004a4430?)
	/usr/local/go/src/cmd/compile/internal/gc/obj.go:107 +0x28
cmd/compile/internal/gc.dumpobj1({0x7ffd5299ac6b, 0x24}, 0x3)
	/usr/local/go/src/cmd/compile/internal/gc/obj.go:63 +0x17b
cmd/compile/internal/gc.dumpobj()
	/usr/local/go/src/cmd/compile/internal/gc/obj.go:44 +0x36
cmd/compile/internal/gc.Main(0xd4e0b0)
	/usr/local/go/src/cmd/compile/internal/gc/main.go:318 +0x1105
main.main()
	/usr/local/go/src/cmd/compile/main.go:55 +0xdd


Go build failed.

What did you expect to see?

What did you see instead?

@mengzhuo mengzhuo added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Mar 2, 2022
@mengzhuo
Copy link
Contributor

mengzhuo commented Mar 2, 2022

@griesemer
Copy link
Contributor

@mdempsky The error comes from iexport.go from some code changed in CL 281292. Any insights?

@griesemer griesemer added this to the Go1.18 milestone Mar 2, 2022
@cuonglm
Copy link
Member

cuonglm commented Mar 2, 2022

This seems to me a problem with noder pass. Somehow, the instantiated function was processed twice with inlining? Disable inlining make the code compiled.

FWIW, the non-generic version works well, and also unified IR code.

@randall77
Copy link
Contributor

I'm not sure entirely what is going on here yet. Might have something to do with function values. if you replace the body of Comparator with:

return func(x, y int) int { return a.CompareInt[int](x,y) }

Then it works.

@aclements
Copy link
Member

Ping. This is marked as a release-blocker and we're very close to the release. Do we understand the underlying issue yet? Given that this causes an ICE instead of mis-compilation, should it be a release-blocker at this point?

@cuonglm
Copy link
Member

cuonglm commented Mar 9, 2022

Ping. This is marked as a release-blocker and we're very close to the release. Do we understand the underlying issue yet? Given that this causes an ICE instead of mis-compilation, should it be a release-blocker at this point?

I think this is a release-blocker, since when it's an ICE on valid code.

@cuonglm
Copy link
Member

cuonglm commented Mar 10, 2022

Also cc @danscales

@gopherbot
Copy link

Change https://go.dev/cl/391574 mentions this issue: cmd/compile: fix re-export closure

@dr2chase
Copy link
Contributor

dr2chase commented Mar 10, 2022

I'm trying a different approach to this, but thus far lack success. The problem appears to be that "wrong" names are left on a closure signature on an Inl.Body, but those names are probably unimportant. Therefore, when constructing an Inl.Body, strip them out from an OCLOSURE node (which is what causes the problem here) to disappear the problem.

Unfortunately, that doesn't seem to work, not sure why, and it also causes a single inscrutable failure in typeparam/issue49246.go. So this is not a good approach, yet.

@randall77
Copy link
Contributor

Reopening for backport to 1.18 release branch.

@randall77 randall77 reopened this Mar 11, 2022
@dmitshur dmitshur added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Mar 11, 2022
@gopherbot
Copy link

Change https://go.dev/cl/391774 mentions this issue: cmd/compile: fix re-export closure

gopherbot pushed a commit that referenced this issue Mar 14, 2022
For hidden closure built during stenciling to implement a function
instantiation, the function may come from other package, not local
package, which causes the ICE for code that re-export the hidden closure
after inlining.

To fix it, use the closure package for export writer when writing out
the closure itself.

Fixes #51423

Change-Id: I23b067ba14e2d602a0fc3b2e99bd9317afbe53ff
Reviewed-on: https://go-review.googlesource.com/c/go/+/391574
Trust: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
(cherry picked from commit 9743e9b)
Reviewed-on: https://go-review.googlesource.com/c/go/+/391774
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
@dmitshur
Copy link
Contributor

Closed by merging commit 4b9b25a (CL 391774) to release-branch.go1.18.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. release-blocker
Projects
None yet
Development

No branches or pull requests

9 participants