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

reflect: Value.Seq panicking on functional iterator methods [1.24 backport] #71876

Closed
gopherbot opened this issue Feb 21, 2025 · 3 comments
Closed
Labels
CherryPickApproved Used during the release process for point releases compiler/runtime Issues related to the Go compiler and/or runtime.
Milestone

Comments

@gopherbot
Copy link
Contributor

@mknyszek requested issue #71874 to be considered for backport to the next 1.24 minor release.

@gopherbot Please open backport issues for Go 1.23 and Go 1.24.

@gopherbot gopherbot added the CherryPickCandidate Used during the release process for point releases label Feb 21, 2025
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Feb 21, 2025
@gopherbot gopherbot added this to the Go1.24.1 milestone Feb 21, 2025
@mknyszek
Copy link
Contributor

This issue is clearly not that important given that we only encountered any feedback post-1.24 for a feature added in Go 1.23, but the fix is small and simple and I don't think we should leave it broken for all of Go 1.23 and Go 1.24.

@gopherbot
Copy link
Contributor Author

Change https://go.dev/cl/651515 mentions this issue: [release-branch.go1.24] reflect: correctly handle method values in Seq

@prattmic prattmic added the CherryPickApproved Used during the release process for point releases label Feb 26, 2025
@gopherbot gopherbot removed the CherryPickCandidate Used during the release process for point releases label Feb 26, 2025
gopherbot pushed a commit that referenced this issue Feb 26, 2025
Currently method values aren't correctly handled in Seq because we call
canRangeFunc on the reciever type, not the method value type, when we're
handling a method value. reflect.Value.Type has the logic to obtain the
method value type from the Value.

This change slightly refactors reflect.Value.Type into a separate
function so we can obtain the correct type as an abi.Type and pass it
off to canRangeFunc (and canRangeFunc2).

For #71874.
Fixes #71876.

Change-Id: Ie62dfca2a84b8f2f816bb87ff1ed1a58a7bb8122
Reviewed-on: https://go-review.googlesource.com/c/go/+/651416
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Michael Knyszek <mknyszek@google.com>
(cherry picked from commit d93f6df)
Reviewed-on: https://go-review.googlesource.com/c/go/+/651515
@gopherbot
Copy link
Contributor Author

Closed by merging CL 651515 (commit 5ffdb9c) to release-branch.go1.24.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CherryPickApproved Used during the release process for point releases compiler/runtime Issues related to the Go compiler and/or runtime.
Projects
None yet
Development

No branches or pull requests

3 participants