cmd/compile: conversion from int/float typed constant to complex variable changed in 1.14

[JetSetIlly]

What version of Go are you using (go version)?

$ go version
go version go1.14.1 linux/amd64

and

$ go version
go version go1.13.6 linux/amd64

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

go env Output

$ go env

GO111MODULE="auto" GOARCH="amd64" GOBIN="/home/user/Go/go/bin" GOCACHE="/home/user/.cache/go-build" GOENV="/home/user/.config/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="linux" GOINSECURE="" GONOPROXY="" GONOSUMDB="" GOOS="linux" GOPATH="/home/user/Go/go" GOPRIVATE="" GOPROXY="direct" GOROOT="/home/user/Go/go-current" GOSUMDB="off" GOTMPDIR="" GOTOOLDIR="/home/user/Go/go-current/pkg/tool/linux_amd64" GCCGO="gccgo" AR="ar" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build444610156=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Ran the following test program for both specified versions.

package main

import "testing"

// int -> complex

const constInt = 1

func TestConstInt(t *testing.T) {
	_ = complex64(constInt)
}

const constIntExplicit = int(1)

func TestConstIntExplicit(t *testing.T) {
	_ = complex64(constIntExplicit)
}

func TestVarInt(t *testing.T) {
	varInt := 1
	_ = complex64(varInt)
}

func TestVarIntExplicit(t *testing.T) {
	varIntExplicit := int(1)
	_ = complex64(varIntExplicit)
}

// float -> complex

const constFloat = 1.0

func TestConstFloat(t *testing.T) {
	_ = complex64(constFloat)
}

const constFloatExplicit = float64(1.0)

func TestConstFloatExplicit(t *testing.T) {
	_ = complex64(constFloatExplicit)
}

func TestVarFloat(t *testing.T) {
	varFloat := 1.0
	_ = complex64(varFloat)
}

func TestVarFloatExplicit(t *testing.T) {
	varFloatExplicit := float64(1.0)
	_ = complex64(varFloatExplicit)
}

What did you expect to see?

The test results to be the same for go version 1.13.6 and 1.14.1

What did you see instead?

Whereas both versions fail (correctly) when converting variable int/float to complex, they behave differently when converting typed constants to complex.

	1.13.6	1.14.1
const int	y	y
const int (explicit type)	y	n
variable int	n	n
variable int (explicit type)	n	n
const float	y	y
const float (explicit type)	y	n
variable float	n	n
variable float (explicit type)	n	n

The results for go version 1.14.1 are the same for v1.14

[randall77]

@griesemer

[ianlancetaylor]

This is a change in compiler behavior, so I'm marking it as a release blocker for 1.15. If we decide that the change was in error, then we need to backport the fix to the 1.14 release branch. My quick reading of the spec is that it is unclear in this area, but I may have missed something.

CC @mdempsky because this may be due to https://golang.org/cl/187657.

[mdempsky]

Minimized test case:

package p

const _ = complex128(int(0))

I think it should be accepted. Conversions says "A constant value x can be converted to type T if x is representable by a value of T." And Representability says "A constant x is representable by a value of type T if one of the following conditions applies: - x is in the set of values determined by T. [...]"

int(0) is a (typed) constant value, and 0 is in the set of values determined by complex128.

[mdempsky]

CC @mdempsky because this may be due to https://golang.org/cl/187657.

Yeah. When writing that CL I assumed that whether we can convert (x : T) to U was simply a function of T and U. But in the case of T being an integer or floating point type and U being a complex type (or vice versa), it also depends on whether x is a constant.

[gopherbot]

Change https://golang.org/cl/226197 mentions this issue: cmd/compile: fix constant conversion involving complex types

[ianlancetaylor]

Looks like we're going back to the 1.13 behavior. I'll let @griesemer review the CL, but:

@gopherbot Please open a backport to 1.14.

The compiler behavior changed the way it handles constant conversions. This can break existing programs with no workaround other than rewriting the program, which should not be needed.

[gopherbot]

Backport issue(s) opened: #38122 (for 1.13), #38123 (for 1.14).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases.

[griesemer]

I agree with the general assessment. Generally speaking, numeric constant conversions are valid if the converted constant can be represented by the new type.

[gopherbot]

Change https://golang.org/cl/232719 mentions this issue: [release-branch.go1.14] cmd/compile: fix constant conversion involving complex types