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.

Sign up for GitHub

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

Jump to bottom

runtime: endless traceback when panic in generics funtion [1.20 backport] #58531

Closed
gopherbot opened this issue Feb 14, 2023 · 2 comments
Closed

runtime: endless traceback when panic in generics funtion [1.20 backport] #58531

gopherbot opened this issue Feb 14, 2023 · 2 comments
Labels
CherryPickApproved Used during the release process for point releases compiler/runtime Issues related to the Go compiler and/or runtime. FrozenDueToAge
Milestone
Go1.20.2

Comments

@gopherbot
Copy link

@mdempsky requested issue #58513 to be considered for backport to the next 1.20 minor release.

Extending the same kludge from 6a801d3 to synthetic closures fixes the issue. That's probably the easiest solution for backporting to 1.20.

@gopherbot Please backport to Go 1.20.
@gopherbot gopherbot added the CherryPickCandidate Used during the release process for point releases label Feb 14, 2023
@gopherbot gopherbot mentioned this issue Feb 14, 2023
Closed
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Feb 14, 2023
@gopherbot gopherbot added this to the Go1.20.2 milestone Feb 14, 2023
@prattmic prattmic added the CherryPickApproved Used during the release process for point releases label Feb 15, 2023
@gopherbot gopherbot removed the CherryPickCandidate Used during the release process for point releases label Feb 15, 2023
@gopherbot
Copy link
Author

Change https://go.dev/cl/471677 mentions this issue: [release-branch.go1.20] cmd/compile/internal/noder: correct positions for synthetic closures

@gopherbot
Copy link
Author

Closed by merging 0f4483c to release-branch.go1.20.

gopherbot pushed a commit that referenced this issue Feb 28, 2023
@mdempsky @gopherbot
[release-branch.go1.20] cmd/compile/internal/noder: correct positions…
0f4483c 
… for synthetic closures

When inlining functions that contain function literals, we need to be
careful about position information. The OCLOSURE node should use the
inline-adjusted position, but the ODCLFUNC and its body should use the
original positions.

However, the same problem can arise with certain generic constructs,
which require the compiler to synthesize function literals to insert
dictionary arguments.

go.dev/cl/425395 fixed the issue with user-written function literals
in a somewhat kludgy way; this CL extends the same solution to
synthetic function literals.

This is all quite subtle and the solutions aren't terribly robust, so
longer term it's probably desirable to revisit how we track inlining
context for positions. But for now, this seems to be the least bad
solution, esp. for backporting to 1.20.

Updates #54625.
Fixes #58531.

Change-Id: Icc43a70dbb11a0e665cbc9e6a64ef274ad8253d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/468415
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
(cherry picked from commit 873c14cec730ee278848f7cc58d2b4d89ab52288)
Reviewed-on: https://go-review.googlesource.com/c/go/+/471677
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
romaindoumenc pushed a commit to TroutSoftware/go that referenced this issue Mar 3, 2023
@mdempsky @romaindoumenc
[release-branch.go1.20] cmd/compile/internal/noder: correct positions…
4a6388a 
… for synthetic closures

When inlining functions that contain function literals, we need to be
careful about position information. The OCLOSURE node should use the
inline-adjusted position, but the ODCLFUNC and its body should use the
original positions.

However, the same problem can arise with certain generic constructs,
which require the compiler to synthesize function literals to insert
dictionary arguments.

go.dev/cl/425395 fixed the issue with user-written function literals
in a somewhat kludgy way; this CL extends the same solution to
synthetic function literals.

This is all quite subtle and the solutions aren't terribly robust, so
longer term it's probably desirable to revisit how we track inlining
context for positions. But for now, this seems to be the least bad
solution, esp. for backporting to 1.20.

Updates golang#54625.
Fixes golang#58531.

Change-Id: Icc43a70dbb11a0e665cbc9e6a64ef274ad8253d1
Reviewed-on: https://go-review.googlesource.com/c/go/+/468415
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
(cherry picked from commit 873c14cec730ee278848f7cc58d2b4d89ab52288)
Reviewed-on: https://go-review.googlesource.com/c/go/+/471677
Auto-Submit: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
@golang golang locked and limited conversation to collaborators Feb 28, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
CherryPickApproved Used during the release process for point releases compiler/runtime Issues related to the Go compiler and/or runtime. FrozenDueToAge
Projects
None yet
Milestone
Go1.20.2
Development

No branches or pull requests
2 participants
@prattmic @gopherbot