Skip to content

cmd/compile: fail to compile package in 1.24 [1.24 backport] #71829

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

Closed
gopherbot opened this issue Feb 19, 2025 · 2 comments
Closed

cmd/compile: fail to compile package in 1.24 [1.24 backport] #71829

gopherbot opened this issue Feb 19, 2025 · 2 comments
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

@cuonglm requested issue #71680 to be considered for backport to the next 1.24 minor release.

@gopherbot please backport this to go1.24 release.

This issue cause the compiler hangs for normal/existed users code.

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

Change https://go.dev/cl/650555 mentions this issue: [release-branch.go1.24] cmd/compile: avoid infinite recursion when inlining closures

@dmitshur dmitshur added CherryPickApproved Used during the release process for point releases and removed CherryPickCandidate Used during the release process for point releases labels Feb 19, 2025
@gopherbot
Copy link
Contributor Author

Closed by merging CL 650555 (commit eb58df7) to release-branch.go1.24.

gopherbot pushed a commit that referenced this issue Feb 19, 2025
…lining closures

CL 630696 changes budget for once-called closures, making them more
inlinable. However, when recursive inlining involve both the closure and
its parent, the inliner goes into an infinite loop:

	parent (a closure)  -> closure -> parent -> ...

The problem here dues to the closure name mangling, causing the inlined
checking condition failed, since the closure name affects how the
linker symbol generated.

To fix this, just prevent the closure from inlining its parent into
itself, avoid the infinite inlining loop.

Fixes #71829

Change-Id: Ib27626d70f95e5f1c24a3eb1c8e6c3443b7d90c8
Reviewed-on: https://go-review.googlesource.com/c/go/+/649656
Reviewed-by: David Chase <[email protected]>
Auto-Submit: Cuong Manh Le <[email protected]>
LUCI-TryBot-Result: Go LUCI <[email protected]>
Reviewed-by: Michael Knyszek <[email protected]>
Reviewed-on: https://go-review.googlesource.com/c/go/+/650555
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

2 participants