8000 cmd/compile: stronger constant propagation around closures · Issue #73601 · golang/go · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

cmd/compile: stronger constant propagation around closures #73601

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

Open
adonovan opened this issue May 5, 2025 · 1 comment
Open

cmd/compile: stronger constant propagation around closures #73601

adonovan opened this issue May 5, 2025 · 1 comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. FeatureRequest Issues asking for a new feature that does not need a proposal. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Performance
Milestone

Comments

@adonovan
Copy link
Member
adonovan commented May 5, 2025

I notice that the use of a local variable to hold a function (e.g. for brevity) doesn't prevent the compiler from treating the variable as an alias for the function, and dispatching calls statically. However, if the variable is referenced from an inner closure, it is treated as a true variable, resulting in a dynamic call:

func f() any {
	escape := html.EscapeString
	println(escape("foo")) // static call
	return func() {
		println(escape("foo")) // dynamic call
	}
}

The closure may be latent, in the case of a range-over-func:

func f(seq iter.Seq[string]) {
	escape := html.EscapeString
	println(escape("foo")) // static call
	for s := range seq {
		println(escape(s)) // dynamic call
	}
}

This is another facet of #73524 (comment), where closures defeat constant propagation of outer single-assignment variables.

@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label May 5, 2025
@adonovan adonovan added the FeatureRequest Issues asking for a new feature that does not need a proposal. label May 5, 2025
@cherrymui
Copy link
Member

cc @dr2chase @golang/compiler

@cherrymui cherrymui added this to the Backlog milestone May 6, 2025
@cherrymui cherrymui added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label May 6, 2025
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. FeatureRequest Issues asking for a new feature that does not need a proposal. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Performance
Projects
None yet
Development

No branches or pull requests

3 participants
0