Skip to content

Function expression should be evaluated before arguments #1271

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
Open
nevkontakte opened this issue Feb 25, 2024 · 0 comments
Open

Function expression should be evaluated before arguments #1271

nevkontakte opened this issue Feb 25, 2024 · 0 comments
Labels
bug
Milestone
Go spec compliance

Comments

@nevkontakte
Copy link
Member

Consider the following snippet:

package main

var ok = false

func f() func(int, int) {
	ok = true
	return func(int, int) {}
}

func g() (int, int) {
	if !ok {
		panic("Bad order!")
	}
	return 0, 0
}

func main() {
	f()(g())
}

In it, the f()(g()) should be equivalent to:

funExpr := f()
a, b := g()
funExpr(a, b)

However, in GopherJS it is:

a, b := g()
funExpr := f()
funExpr(a, b)

https://gopherjs.github.io/playground/#/FMGNfOX9RA

https://go.dev/play/p/DGqo4zOvkUM

The bug is here:

gopherjs/compiler/utils.go

Line 119 in e76f823

argExprs = fc.expandTupleArgs(argExprs)
. When a function argument is another function's returned tuple, the inner function is broken out into a separate statement that's evaluated too early. To avoid that we can use ES6 spread operator and avoid a separate statement.
@nevkontakte nevkontakte added this to the Go spec compliance milestone Feb 25, 2024
nevkontakte added a commit to nevkontakte/gopherjs that referenced this issue Feb 25, 2024
@nevkontakte
Diagnose fixedbugs/issue50672.go issue.
deb26d0 
Previously it was masked by missing generics support, but now it
revealed another latent bug:
gopherjs#1271.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
Go spec compliance
Development

No branches or pull requests
1 participant
@nevkontakte