Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Incorrect lhs evaluation order in multi-assignments #1063

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
Closed
nevkontakte opened this issue Sep 17, 2021 · 1 comment
Closed

Incorrect lhs evaluation order in multi-assignments #1063

nevkontakte opened this issue Sep 17, 2021 · 1 comment
Labels
bug

Comments

@nevkontakte
Copy link
Member

The spec says the following:

The assignment proceeds in two phases. First, the operands of index expressions and pointer indirections (including implicit pointer indirections in selectors) on the left and the expressions on the right are all evaluated in the usual order. Second, the assignments are carried out in left-to-right order.

However, gopherjs evaluates lhs expressions at the time of assignment. In situations when one of the assignments modifies a variable referenced by another assignment, the result may be incorrect. For example:

package main

func main() {
        type T struct{ i int }
        var x T
        p := &x
        p, p.i = new(T), 4
        println(p.i, x.i)
}

Go prints 0 4
GopherJS prints 4 0

Related: golang/go#23017.
nevkontakte added a commit to nevkontakte/gopherjs that referenced this issue Sep 17, 2021
@nevkontakte
Mark fixedbugs/issue23017.go as a known failure.
a0dbb0e 
GopherJS breaks lhs expression evaluation order defined by the spec.
Unfortunately, it's not easy to fix and would likely generate a lot more
code for multi-assignments.

An efficient fix would require writing some sort of analysis to
determine if assignments are likely to influence each other, and at the
moment I can't think of how such analysis would work. Without it we
would have to create a whole bunch of extra temporary variables for any
multi-assignment, which will likely lead to a significant increase in
the artifact size. Considering nobody reported this issue so far, I'm
inclined to punt on this issue for now.

gopherjs#1063 tracks this bug.
@nevkontakte nevkontakte mentioned this issue Oct 27, 2021
Open
@nevkontakte
Copy link
Member Author

This seems to be a duplicate of #358, closing in favor of the older issue with more discussion.

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
No milestone
Development

No branches or pull requests
1 participant
@nevkontakte