go/types: untyped int literal is identified as uint in go1.17

[ktye]

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

$ go version
go version go1.17rc1 windows/amd64

Does this issue reproduce with the latest release?

the issue is different behaviour between go1.17 and go1.16

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

go env Output

$ go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\abc\AppData\Local\go-build
set GOENV=C:\Users\abc\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\dat\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:/dat/go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=c:\go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=c:\go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.17rc1
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=C:\k\i\go.mod
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\msys64\tmp\go-build3488873506=/tmp/go-build -gno-record-gcc-switches

What did you do?

in go1.17 go/types identifies the literal 3 as uint, while go1.16 reports an untyped int kind.

func shift(x int32) int32 { return x << 3 }

see:
https://play.golang.org/p/WuuJ6PGlylQ

What did you expect to see?

Go1.16 (and the playground) shows:

Types and Values of each expression:
 4:14 | int32               | int32
 4:21 | int32               | int32
 4:36 | x                   | int32
 4:36 | x << 3              | int32
 4:41 | 3                   | untyped int = 3

What did you see instead?

Go1.17 shows:

Types and Values of each expression:
 4:14 | int32               | int32
 4:21 | int32               | int32
 4:36 | x                   | int32
 4:36 | x << 3              | int32
 4:41 | 3                   | uint = 3

Is this kind of change in go/types considered as a bug?

[prattmic]

cc @griesemer @danscales

[cuonglm]

This at least conform to the spec:

The right operand in a shift expression must have integer type or be an untyped constant representable by a value of type uint

[findleyr]

This is a consequence of CL 291316 -- bisected to confirm.

The right operand in a shift expression must have integer type or be an untyped constant representable by a value of type uint

Shifts are particularly tricky with respect to type conversion. In this case, I think it might be ambiguous in the spec. Consider the full quote (emphasis mine):

Except for shift operations, if one operand is an untyped constant and the other operand is not, the constant is implicitly converted to the type of the other operand.

The right operand in a shift expression must have integer type or be an untyped constant representable by a value of type uint. If the left operand of a non-constant shift expression is an untyped constant, it is first implicitly converted to the type it would assume if the shift expression were replaced by its left operand alone.

Per my reading of this, it's not specified what happens to the type of the right operand. However, note that go/types currently also doesn't handle the left operand correctly. For example, in func _() int32 { return 1 << 3 }, we report the type of 1 as untyped int (Edit: we actually do the right thing if the shift expression is non-constant)

[griesemer]

For this case, the spec only requires that the untyped RHS constant be representable by a value of type uint; it doesn't say that the operand is actually converted to or given the type uint.

For comparison, in the section on Index expressions where we have similar requirements on constant indices, the spec states explicitly that "a constant index must be non-negative and representable by a value of type int" and "a constant index that is untyped is given type int". The same is true for make expressions, and go/types does the conversions to int.

However, the "a constant index that is untyped is given type int" phrase is missing in the section on Slice expressions, yet go/types also converts constant indices to int.

Finally, in the section on Array types, the spec only requires representability but doesn't assign a type, and go/types doesn't convert.

The "is given type int" part is relevant in context and decides what type is given to other untyped expressions, such as shifts. For more examples, see this expanded test.

The go/types behavior with respect to these types seems a bit inconsistent, but so is the spec.

The spec should probably apply the same rules for slice expression indices as for ordinary index expressions.
go/types should probably stick with untyped int in this case.

[gopherbot]

Change https://golang.org/cl/336912 mentions this issue: [dev.typeparams] go/types: don't eagerly convert untyped RHS of shifts to uint

[findleyr]

CC @golang/release

I marked this issue as a release blocker. It would be good to fix it for 1.17, and we can probably merge a fix today or tomorrow. Please let me know if this causes disruptions to the release, or if there's anything else we should do.

[gopherbot]

Change https://golang.org/cl/337529 mentions this issue: go/types: preserve untyped constants on the RHS of a shift expression

[gopherbot]

Change https://golang.org/cl/338195 mentions this issue: [dev.typeparams] cmd/compile/internal/types2: preserve untyped constants on the RHS of a shift expression