cmd/compile: internal compiler error: weird package in name: .dict0 => .dict0 from "", not "test/p" #52117
Comments
|
Sounds like we should reopen #51423 ? |
|
I can not reproduce the problem of #51423, but this issue can be reproduced.
It seems that caused by the exported func name |
|
cc @cuonglm @randall77 per original CL |
|
@hopehook Yes, the test case is a bit different with previous one, and the original CL doesn't covers this new case.
the |
|
I've found that if you use p.Slice[int] normally, it works fine, or if you don't export the Test function.
package main
import (
"fmt"
"test/p"
)
func main() {
Test()
}
func Test() {
var x p.Slice[int]
fmt.Println(x.Comparator()(1, 1))
}
package main
import (
"test/p"
)
func main() {
test()
}
func test() {
var _ p.Slice[int]
} |
cuonglm
added
the
NeedsInvestigation
|
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. |
|
Change https://go.dev/cl/398474 mentions this issue: |
|
Should we backport this? @randall77 @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? |
I think yes, so we don't need to be re-typechecked on import.
Hmm, not sure that's the case for iimport.go today. |
|
@cuonglm will this be fixed in 1.18.1? |
|
@gopherbot please backport this to 1.18 |
|
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. |
|
Change https://go.dev/cl/403197 mentions this issue: |
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
added
NeedsFix
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
go compiler panicked with generics code, i made a reproduce demo at https://go.dev/play/p/4sC7oDiNFJs
the error logs:
this bug is similar with #51423, i have made a temporary workaround in my code by change
return Compare[T]toreturn 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 existsWhat did you expect to see?
What did you see instead?
The text was updated successfully, but these errors were encountered: