"panic: runtime error: integer divide by zero" when make-ing an array of zero-sized elems

[ALTree]

$ tinygo version
tinygo version 0.22.0 linux/amd64 (using go version go1.17.8 and LLVM version 13.0.0)

Building this program:

package main

import "fmt"

func main() {
	i := 4
	m := make([]struct{}, i)
	fmt.Println(m)
}

triggers a panic in tinygo:

$ tinygo build -o crash.o crash.go 

panic: runtime error: integer divide by zero

goroutine 54 [running]:
github.com/tinygo-org/tinygo/compiler.(*compilerContext).maxSliceSize(0xc000654680, {0x512df38})
	/home/runner/work/tinygo/tinygo/compiler/compiler.go:1552 +0xb5
github.com/tinygo-org/tinygo/compiler.(*builder).createExpr(0xc00113e360, {0x5134910, 0xc00136d440})
	/home/runner/work/tinygo/tinygo/compiler/compiler.go:1793 +0x472
github.com/tinygo-org/tinygo/compiler.(*builder).createInstruction(0xc00113e360, {0x51348c8, 0xc00136d440})
	/home/runner/work/tinygo/tinygo/compiler/compiler.go:1129 +0x8ea
github.com/tinygo-org/tinygo/compiler.(*builder).createFunction(0xc00113e360)
	/home/runner/work/tinygo/tinygo/compiler/compiler.go:1034 +0x1865
github.com/tinygo-org/tinygo/compiler.(*compilerContext).createPackage(0xc000654680, {0xc00161f2c0}, 0xc001305500)
	/home/runner/work/tinygo/tinygo/compiler/compiler.go:773 +0x62f
github.com/tinygo-org/tinygo/compiler.CompilePackage({0xc0003f9da0, 0xc00157ae10}, 0xc000462540, 0xc001305500, {0x5}, 0x0, 0x0)
	/home/runner/work/tinygo/tinygo/compiler/compiler.go:280 +0x377
github.com/tinygo-org/tinygo/builder.Build.func1(0x0)
	/home/runner/work/tinygo/tinygo/builder/build.go:258 +0x196
github.com/tinygo-org/tinygo/builder.runJob(0xc00133c540, 0x0)
	/home/runner/work/tinygo/tinygo/builder/jobs.go:222 +0x4f
created by github.com/tinygo-org/tinygo/builder.runJobs
	/home/runner/work/tinygo/tinygo/builder/jobs.go:123 +0x5f8

It compiles and prints [{} {} {} {}] -as expected- with the main Go toolchain.

[dkegel-fastly]

This should be fixed now.

What real-world situation triggers this? How important is minimizing allocations in that case? I hear the fix that was landed may have missed an opportunity to skip one allocation (see discussion on #2750).

[ALTree]

What real-world situation triggers this?

None, it's a corner case of the language.

The pattern of making a []struct{} does appear 8 times in the Go repository, all of them in test files:

$ ag -Q "make([]struct{}"

src/runtime/race/testdata/slice_test.go
231:	a := make([]struct{}, 10)

test/fixedbugs/bug352.go
10:var y = make([]struct{}, 10)

test/fixedbugs/issue7550.go
20:        a := make([]struct{}, length)
21:        b := make([]struct{}, length)

test/fixedbugs/issue6399.go
20:	_ = make([]struct{}, 1)

test/append.go
147:	{"make c", append([]struct{}{}, make([]struct{}, 0)...), []struct{}{}},
148:	{"make d", append([]struct{}{}, make([]struct{}, 2)...), make([]struct{}, 2)},

How important is minimizing allocations in that case?

I don't think it's particularly important. I can't think of any situation where makeing a slice of struct{}s would be particularly useful.

[aykevl]

Yeah it would be nice, but only if it can be done by rearranging code (no extra complexity or lines of code). IMHO very low priority considering how little this feature is used.

On the other hand, we do actually have some optimizations for make(chan struct{}), because that's an actually useful feature.