cmd/link: panic: index out of range [23] with length 0

[ALTree]

$ gotip version
go version devel go1.18-6c36c332fe Tue Nov 16 18:36:59 2021 +0000 linux/amd64

package main

func f() any {
	var a []any
	return a[0]
}

func main() {
	f()
}

$ gotip build crash.go 

# command-line-arguments
panic: runtime error: index out of range [23] with length 0

goroutine 1 [running]:
cmd/link/internal/ld.decodetypeKind(...)
	/home/alberto/gotip/src/cmd/link/internal/ld/decodesym.go:53
cmd/link/internal/ld.(*dwctxt).newtype(0xc000110af0, 0x87df)
	/home/alberto/gotip/src/cmd/link/internal/ld/dwarf.go:537 +0x23e7
cmd/link/internal/ld.(*dwctxt).defgotype(0xc000110af0, 0x87df)
	/home/alberto/gotip/src/cmd/link/internal/ld/dwarf.go:528 +0x125
cmd/link/internal/ld.(*dwctxt).newtype(0xc000110af0, 0x37b7)
	/home/alberto/gotip/src/cmd/link/internal/ld/dwarf.go:659 +0xb29
cmd/link/internal/ld.(*dwctxt).defgotype(0xc000110af0, 0x37b7)
	/home/alberto/gotip/src/cmd/link/internal/ld/dwarf.go:528 +0x125
cmd/link/internal/ld.(*dwctxt).importInfoSymbol(0xc000110af0, 0x0?)
	/home/alberto/gotip/src/cmd/link/internal/ld/dwarf.go:1134 +0x33c
cmd/link/internal/ld.(*dwctxt).dwarfVisitFunction(0xc000110af0, 0x4?, 0xc0000a20d0)
	/home/alberto/gotip/src/cmd/link/internal/ld/dwarf.go:1717 +0x425
cmd/link/internal/ld.dwarfGenerateDebugInfo(0xc00004e000)
	/home/alberto/gotip/src/cmd/link/internal/ld/dwarf.go:1876 +0x1528
cmd/link/internal/ld.Main(_, {0x20, 0x20, 0x1, 0x7, 0x10, 0x0, {0x0, 0x0}, {0x67cbc1, ...}, ...})
	/home/alberto/gotip/src/cmd/link/internal/ld/main.go:273 +0xe73
main.main()
	/home/alberto/gotip/src/cmd/link/main.go:69 +0xfe5

cc @randall77 @cherrymui

[randall77]

@thanm

go run works fine. go build doesn't. Seems DWARF related.

[thanm]

What's going on here is that the type in question (type.go.builtin.any) is one of those basic builtins that the compiler expects will be emitted when we compile the runtime, so it doesn't bother to emit it for every package. See

https://go.googlesource.com/go/+/5e59d6ebd110a7c19770c7d996930ff379ba5726/src/cmd/compile/internal/reflectdata/reflect.go#1733

... meaning that it appears as unresolved at link time (we would get a similar failure mode if the compiler failed to emit an entry for "type.uintptr" when building the runtime, or some other core builtin type). Probably the easiest way to handle this would be force a reference to the type when building the runtime package, I'll send a CL.

What is a bit puzzling about this one is why it hasn't come up before? Not sure about that.

[thanm]

Wondering if this same thing could come up with other generics predefined types, maybe 'comparable'? I tried to construct a test case for that but ran into

test/fixedbugs/issue49619.go:17:10: interface is (or embeds) comparable

[gopherbot]

Change https://golang.org/cl/364377 mentions this issue: cmd/compile: emit definition of 'any' when compiling runtime

[danscales]

This may be happening now because of @findleyr 's recent CL to try to preserve the 'any' type when converting from types2 to types1 (better error messages, etc.): https://go-review.googlesource.com/c/go/+/363974

[findleyr]

I don't really understand the failure mode, but yes it seems highly likely that this is related to my CL. Before that change, I suspect we may never have produced types.AnyType.

[findleyr]

We can revert that CL, of course, but it would be nice if we could fix forward; preserving the identity of any is a nice usability improvement.

[thanm]

@findleyr fix forward would be my choice. Compiler and linker already have a good deal of special cases for the runtime package when it comes to DWARF generation.

[findleyr]

@thanm sounds good, thanks!

[gopherbot]

Change https://golang.org/cl/364614 mentions this issue: cmd/compile: emit definition of 'any' only if generic enabled