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: panic: runtime error: index out of range [0] with length 0 #51765

Closed
blaubaer opened this issue Mar 17, 2022 · 8 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@blaubaer
Copy link

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

$ go version
go version go1.18 windows/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
set GO111MODULE=on
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\demo\AppData\Local\go-build
set GOENV=C:\Users\demo\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\demo\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\demo\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.18
set GCCGO=gccgo
set GOAMD64=v1
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=C:\development\github.com\blaubaer\demo
set GOWORK=
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:\Users\demo\AppData\Local\Temp\go-build2763200917=/tmp/go-build -gno-record-gcc-switches

What did you do?

I was using the following code (https://go.dev/play/p/KwmzJ6V1JwN)

package main

import (
	"errors"
	"log"
)

var (
	ErrEof = errors.New("end of iterator reached")
)

type empty[T any] struct{}

func (this *empty[T]) Next() (empty T, _ error) {
	return empty, ErrEof
}

func doSomethingWithIterator[T any](what interface{ Next() (T, error) }) {
	v, err := what.Next()
	if err != nil {
		log.Fatalln(err)
		return
	}
	log.Println(v)
}

func main() {
	i := &empty[string]{}
	doSomethingWithIterator[string](i)
}

What did you expect to see?

The code compiles and run.

What did you see instead?

# github.com/blaubaer/demo
.\demo.go:29:33: internal compiler error: panic: runtime error: index out of range [0] with length 0

Please file a bug report including a short program that triggers the error.
https://go.dev/issue/new
@blaubaer blaubaer changed the title affected/package: cmd/go: internal compiler error: panic: runtime error: index out of range [0] with length 0 Mar 17, 2022
@ALTree ALTree changed the title cmd/go: internal compiler error: panic: runtime error: index out of range [0] with length 0 cmd/compile: internal compiler error: panic: runtime error: index out of range [0] with length 0 Mar 17, 2022
@ALTree ALTree added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Mar 17, 2022
@ALTree ALTree added this to the Go1.19 milestone Mar 17, 2022
@ALTree
Copy link
Member

ALTree commented Mar 17, 2022

Thanks for reporting this. tip is also affected.

cc @randall77 @danscales

@findleyr
Copy link
Contributor

CC @mdempsky as well, though this appears to compile without errors with GOEXPERIMENT=unified.

@randall77
Copy link
Contributor

This appears to be due to confusion between empty, the generic type, and empty, the local variable of the Next function. The code thinks it is trying to get the type parameters of the former, but it is in fact trying to get the type parameters of the latter, which fails.
Not sure why yet.

@cuonglm cuonglm self-assigned this Mar 20, 2022
@cuonglm cuonglm added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Mar 20, 2022
@gopherbot
Copy link

Change https://go.dev/cl/394076 mentions this issue: cmd/compile: make a copy when storing original generic type sym

@cuonglm
Copy link
Member

cuonglm commented Mar 20, 2022

This appears to be due to confusion between empty, the generic type, and empty, the local variable of the Next function. The code thinks it is trying to get the type parameters of the former, but it is in fact trying to get the type parameters of the latter, which fails. Not sure why yet.

The problem is that noder will store the symbol of the generic base type. But the symbol declaration maybe changed when re-declaring variable with the same name. So the code:

origRParams := deref(orig).OrigSym().Def.(*ir.Name).Type().RParams()

will return wrong type parameters.

@gopherbot
Copy link

Change https://go.dev/cl/394274 mentions this issue: cmd/compile: replace Type.OrigSym with Type.OrigType

@mdempsky
Copy link
Member

@gopherbot please backport to Go 1.18; this is a compiler bug that could theoretically lead to silent miscompilation of valid user code

@gopherbot
Copy link

Backport issue(s) opened: #51855 (for 1.18).

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

@rsc rsc unassigned cuonglm Jun 22, 2022
@golang golang locked and limited conversation to collaborators Jun 22, 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.
Projects
None yet
Development

No branches or pull requests

7 participants