Skip to content
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

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

Closed
ktye opened this issue Jul 16, 2021 · 8 comments
Closed

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

ktye opened this issue Jul 16, 2021 · 8 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. release-blocker
Milestone

Comments

@ktye
Copy link

ktye commented Jul 16, 2021

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 prattmic added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jul 16, 2021
@prattmic
Copy link
Member

cc @griesemer @danscales

@cuonglm
Copy link
Member

cuonglm commented Jul 16, 2021

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

@dmitshur dmitshur added this to the Go1.17 milestone Jul 16, 2021
@findleyr
Copy link
Contributor

findleyr commented Jul 18, 2021

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
Copy link
Contributor

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
Copy link

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

@findleyr findleyr added NeedsFix The path to resolution is known, but the work has not been done. release-blocker labels Jul 26, 2021
@gopherbot gopherbot removed the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jul 26, 2021
@findleyr
Copy link
Contributor

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
Copy link

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

@gopherbot
Copy link

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

@golang golang locked and limited conversation to collaborators Jun 23, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. release-blocker
Projects
None yet
Development

No branches or pull requests

7 participants