cmd/compile: miscompilation of comparison between type parameter and interface

[mdempsky]

The program below should run quietly, but instead it prints:

FAIL: if i != t
FAIL: switch i
FAIL: switch t

Marking as a release blocker, because this seems like a miscompilation bug that users could plausibly actually run into. But I think it might be reasonable to punt fixing it to a point release.

A possible workaround here is to replace each use of t with any(t).

package main

func f[T comparable](i any) {
	var t T

	if i != t {
		println("FAIL: if i != t")
	}

	switch i {
	case t:
		// ok
	default:
		println("FAIL: switch i")
	}

	switch t {
	case i:
		// ok
	default:
		println("FAIL: switch t")
	}
}

func main() {
	f[int](int(0))
}

/cc @griesemer @ianlancetaylor @randall77

[mdempsky]

More comprehensive test case, that also exercises non-empty interfaces:

package main

type I interface { M() }

type myint int
func (myint) M() {}

func f[T comparable, U interface{ comparable; I }](a any, i I) {
        var t T
        var u U

        if a != t {
                println("FAIL: if a != t")
        }
        switch a {
        case t:
        default:
                println("FAIL: switch a, case t")
        }
        switch t {
        case a:
        default:
                println("FAIL: switch t, case a")
        }

        if a != u {
                println("FAIL: if a != u")
        }
        switch a {
        case u:
        default:
                println("FAIL: switch a, case u")
        }
        switch u {
        case a:
        default:
                println("FAIL: switch u, case a")
        }

        if i != u {
                println("FAIL: if i != u")
        }
        switch i {
        case u:
        default:
                println("FAIL: switch i, case u")
        }
        switch u {
        case i:
        default:
                println("FAIL: switch u, case i")
        }
}

func main() {
        f[myint, myint](myint(0), myint(0))
}

[ianlancetaylor]

CC @randall77

[findleyr]

It seems plausible that this could lead to subtle bugs in real code, for example:
https://go.dev/play/p/MQ1qi27IjUJ?v=gotip

[aclements]

Do we understand the underlying issue here? If so, do we have a plan to fix it?

[eliben]

Do we understand the underlying issue here? If so, do we have a plan to fix it?

We chatted about this on Monday and decided to flag this as an error in the compiler for 1.18, with a hope for a more fundamental fix in 1.19

[jeremyfaller]

From a conversation with @eliben, it looks like he's counting on @mdempsky or @randall77 to take a look. From Eli – "We decided to flag it as an error because we don't have a good undestanding of how to compare interface values with generic values at this time"

Should be done by release time.

[gopherbot]

Change https://go.dev/cl/391315 mentions this issue: go/types, types2: disallow interface vs type parameter comparison

[griesemer]

Acceptance of https://go.dev/cl/391315 will change this from a release blocker to a bug for Go 1.19.

A better temp. solution might be to report this issue in the compiler proper; this CL is just here as a last resort.

[ianlancetaylor]

I sent https://go.dev/cl/391374 that fixes some of the cases and give an error for a case that is harder to handle.

I'll let @randall77 and @mdempsky decide which approach to take.

[gopherbot]

Change https://go.dev/cl/391374 mentions this issue: cmd/compile: use correct type when comparing generic to interface

[randall77]

Sorry, I've been away for a few days.
The problem here, at least for the != test, is that there's an implicit OCONVIFACE that the stenciler needs to see in order to do the comparison properly. I think we actually fixed that at one point, in CL 336992 perhaps? Not sure if there was a regression since. Looks like that CL didn't have a test, unfortunately. I'll look some more.

[gopherbot]

Change https://go.dev/cl/391475 mentions this issue: cmd/compile: fix transform of OEQ/ONE when one arg is a type param