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: hash of unhashable type [4]int32 #65957

Closed
wdvxdr1123 opened this issue Feb 27, 2024 · 6 comments
Closed

cmd/compile: hash of unhashable type [4]int32 #65957

wdvxdr1123 opened this issue Feb 27, 2024 · 6 comments
Assignees
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@wdvxdr1123
Copy link
Contributor

Go version

gotip

Output of go env in your module/workspace:

GOARCH="arm64"
GOOS="darwin"

What did you do?

playground link: https://go.dev/play/p/WAX0OTneh60

What did you see happen?

panic: runtime error: hash of unhashable type [4]int32

goroutine 1 [running]:
main.main()
	/tmp/sandbox3460698193/prog.go:15 +0xc7

What did you expect to see?

no panic

@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Feb 27, 2024
@gopherbot
Copy link

Change https://go.dev/cl/567335 mentions this issue: cmd/compile: mark noalg for pointer to noalg type

@gopherbot
Copy link

Change https://go.dev/cl/567335 mentions this issue: cmd/compile: mark pointer to noalg type as noalg

@randall77
Copy link
Contributor

Here's a simpler reproducer: https://go.dev/play/p/NGky0OURi8R

@wdvxdr1123
Copy link
Contributor Author

I can reproduce with go1.21 and go1.22. Should we backport this fix?

@randall77
Copy link
Contributor

I'm on the fence. We only backport serious issues with no workaround, which I'm not sure this qualifies. It has been a bug since 1.18 and this is the first anyone has reported it. I'm not sure what a workaround might be, though. Does introducing a use of the array type in both packages work as a workaround?

I'll open backports and we can discuss on those issues.

@gopherbot please open backport issues. This issue may warrant backporting. It causes program crashing in some very particular circumstances. (Use of reflect.ArrayOf, and just the right use / nonuse of the corresponding language type in particular packages.)

@gopherbot
Copy link

Backport issue(s) opened: #65982 (for 1.21), #65983 (for 1.22).

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

@dmitshur dmitshur added this to the Go1.23 milestone Feb 28, 2024
@dmitshur dmitshur added the NeedsFix The path to resolution is known, but the work has not been done. label Feb 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

4 participants