cmd/compile: comma ok assignment order is right-to-left for some statements

[trisiak]

When the same variable is used twice in a "comma ok" statement, the assignment is sometimes carried out right-to-left:

• channel (and function result), left-to-right: https://play.golang.org/p/D8340bbwmV
• map, right-to-left: https://play.golang.org/p/wCHIzyEHb0
• type assertion, right-to-left : https://play.golang.org/p/8rGKxiagbA

The specification is consistent and states that:

(...) the assignments are carried out in left-to-right order.

From reading of how OAS2MAP is handled this is clearly an explicit action since the compiler does a rewrite of the statement (https://github.com/golang/go/blob/go1.5.1/src/cmd/compile/internal/gc/walk.go#L808-L881). I could not find the reason for why OAS2DOTTYPE doesn't follow the specification.

This is the case for at least go1.5.1.

[rsc]

Single-program test case: https://play.golang.org/p/ZJgUHH-Qjn

package main

var c = make(chan bool, 10)
func init() { c <- false; c <- false }
var i interface{} = false
func f() (bool, bool) { return false, true }
var m = map[int]bool{0: false}

func main() {
    c <- false

    var x, y bool

    x, y = m[0]
    println("x, y = m[0]:", x, y)
    x, x = m[0]
    println("x, x = m[0]:", x, x, "\n")

    x, y = <-c
    println("x, y = <-c:", x, y)
    x, x = <-c
    println("x, x = <-c:", x, x, "\n")

    x, y = f()
    println("x, y = f():", x, y)
    x, x = f()
    println("x, x = f():", x, x, "\n")

    x, y = i.(bool)
    println("x, y = i.(bool):", x, y)
    x, x = i.(bool)
    println("x, x = i.(bool):", x, x)
}

prints:

x, y = m[0]: false true
x, x = m[0]: false false 

x, y = <-c: false true
x, x = <-c: true true 

x, y = f(): false true
x, x = f(): true true 

x, y = i.(bool): false true
x, x = i.(bool): false false

All the x, x should be true, true, not false, false, because the right-side x should be assigned second.

Great bug. These don't follow the spec because it never occurred to me that they'd be assigning to the same variable, and it was often cheaper to set the "ok" before the "real result".

This might be fixable in order.go rather than in each case.

[gopherbot]

CL https://golang.org/cl/34713 mentions this issue.

[JayNakrani]

golang.org/cl/34713 does the reordering by introducing temporaries in order.go. Dump of main() with the change is here.