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

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

Closed
mcdoker18 opened this issue Jan 15, 2022 · 8 comments
Closed
Labels
NeedsInvestigation
Milestone

Comments

@mcdoker18
Copy link

@mcdoker18 mcdoker18 commented Jan 15, 2022

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 ALTree added this to the Go1.18 milestone Jan 15, 2022
@ALTree
Copy link
Member

@ALTree ALTree commented Jan 15, 2022

Tip regression, thanks for reporting it.

cc @danscales @griesemer

@ALTree ALTree added NeedsInvestigation release-blocker labels Jan 15, 2022
@ALTree ALTree changed the title cmd/compile: "internal compiler error: unexpected untyped type: untyped int" cmd/compile: internal compiler error: unexpected untyped type: untyped int Jan 15, 2022
@danscales
Copy link
Contributor

@danscales danscales commented Jan 16, 2022

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.

@danscales danscales self-assigned this Jan 16, 2022
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Jan 16, 2022

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

@danscales danscales commented Jan 16, 2022

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.

@danscales danscales assigned griesemer and unassigned danscales Jan 16, 2022
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Jan 16, 2022

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

@danscales danscales commented Jan 17, 2022

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

@DemiMarie DemiMarie commented Jan 18, 2022

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

@griesemer griesemer commented Jan 18, 2022

Duplicate of #45117.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation
Projects
None yet
Development

No branches or pull requests

6 participants