cmd/compile: internal compiler error: unexpected untyped type: untyped int

[mcdoker18]

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

$ go version
go version go1.18beta1 darwin/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="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="*"
GOENV="*"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="*"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="*"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="*"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="*"
GOVCS=""
GOVERSION="go1.18beta1"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="*"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/gb/jbymmt5960b34zty5k4mpry40000gn/T/go-build1146860326=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

Build:

package main

func main() {
	var n = 6
	var _ = string(1 << n)
}

What did you see instead?

# command-line-arguments
main.go:5:19: internal compiler error: unexpected untyped type: untyped int

Please file a bug report including a short program that triggers the error.
https://golang.org/issue/new

[ALTree]

Tip regression, thanks for reporting it.

cc @danscales @griesemer

[danscales]

In 1.17 and prior (and also -G=0 mode in 1.18), you get a wrong error:

test.go:5:16: invalid operation: 1 << n (shift of type string)

This seems to be a bug with the OLSH/ORSH case in typecheck.convLit1. As far as I can tell, the code is legal (both untyped values 1 and 6 should be interpreted as ints).

I will work on the crash in the compiler. Despite the crash, this is probably not a release blocker (as noted by @ALTree ), since the case was already marked as illegal code in 1.17 and prior.

[ianlancetaylor]

Actually "invalid operation: 1 << n (shift of type string)" is the correct error. See the discussion of shift expressions at https://go.dev/ref/spec#Operators.

Getting an internal compiler error rather than a proper error is indeed a regression, though I agree that it is not a critical one.

[danscales]

OK, thanks for clarifying! Sounds like this is a types2 typechecker bug then. I will assign to @griesemer for now.

BTW, I actually did look at the spec. This rule:

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.

did not immediately make me think that an explicit outer string() conversion can actually control the assumed type of the left operand. But I do see that there is an example in the spec using uint64(1 << s) in the spec, so I guess the string case should be parallel. Will definitely be good to add a test case for this example.

[ianlancetaylor]

It seems to me that the test is $GOROOT/test/shift1.go, in the line

	v float32 = 1 << s   // ERROR "invalid"

We could certainly add a similar line with string replacing float32 if it makes a difference.

[danscales]

For some reason, the types2 typecheck flags this case as an error:

        var n = 6
        var x string = 1 << n // ERROR "invalid"

but not the example in this bug (and then the compiler gives the internal compiler error):

       var n = 6
       var + = string(1 << n) // ERROR "invalid"

Also, if you replace string with float32, the types2 typechecker catches both cases. So, we do need to include this new example in the shift1.go file.

[DemiMarie]

Actually "invalid operation: 1 << n (shift of type string)" is the correct error. See the discussion of shift expressions at https://go.dev/ref/spec#Operators.

While the error is technically correct, it is still confusing. A better error would be nice.

[griesemer]

Duplicate of #45117.