-
Notifications
You must be signed in to change notification settings - Fork 18k
cmd/compile: wrong evaluation order for map assignment [Go1.8] #22881
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
Comments
Slightly simpler version, as a playground link: https://play.golang.org/p/5hasX7yOX1 |
Looks like a bug to me. The spec says that the right-hand side is first fully evaluated before any assignments take place. A nil-pointer deref causes a runtime panic similar to calling panic() which (immediately) terminates the surrounding function. |
Yeah, this is probably an order.go issue. We can't call mapassign until we know the RHS will evaluate without panicking. At least OIND, OINDEX, ODIV, and OMOD can panic, but are currently allowed after the mapassign call. |
Change https://golang.org/cl/81817 mentions this issue: |
Reopening for backport consideration (both 1.9.3 and 1.8.6). |
This is not only for map
[update] Aha, this may be some different. |
however, if we view left |
Similar to this problem: https://groups.google.com/forum/#!topic/golang-nuts/J3kXXZivlHA |
@go101 The order of evaluation rules are at https://golang.org/ref/spec#Order_of_evaluation. There is no specified order between the function call on the left hand side and the indirection on the right hand side. It's clear that the indirection must happen before the assignment, but there is no requirement that the indirection happen before the function call. |
Then this
The spec says |
Let's take detailed discussion of order of evaluation away from this issue, which is about a specific bug. Thanks. |
Closing proposed backport per discussion in #23005. (This remains fixed in the upcoming 1.10 release.) |
This should print 0, not 1. The nil ptr panic should happen before the insert into m.
It prints 0 up to go 1.7, but starting at go 1.8 it prints 1.
Same thing happens if I use
s[0]
on a nil slice instead of*p
on a nil pointer.The bug goes away if I do
tmp := m[5] + *p; m[5] = tmp
.I'm going to label this as a backportable 1.9.3 issue so we can discuss (and maybe also 1.8.6, but github won't let me multi-milestone an issue), but I kind of lean toward just fixing this in 1.10. It's pretty esoteric, survived more than a release cycle without a bug report, and it is easy to work around.
It's also possible I'm not reading the spec correctly, and this is allowed behavior. @griesemer
Doesn't seem to be SSA related - the AST already has the ops out of order on input to SSA.
The text was updated successfully, but these errors were encountered: