Golang slices: TestIssue68488 seems sensitive to minor stack perturbations

Go version

1.24.4 and tip

Output of go env in your module/workspace:

playground

What did you do?

Add a local variable to slices.TestIssue68488 from #68488.

Modified version on playground: https://go.dev/play/p/HJC9xu8dz-E

func TestIssue68488ExtraVariable(t *testing.T) {
    // Test starts failing if we add these two lines declaring a local variable.
    x := 42
    _ = x

    s := make([]int, 3)
    clone := slices.Clone(s[1:1])
    switch unsafe.SliceData(clone) {
    case &s[0], &s[1], &s[2]:
        t.Error("clone keeps alive s due to array overlap")
    }
}

What did you see happen?

The test starts failing.

prog_test.go:28: clone keeps alive s due to array overlap

What did you expect to see?

It's not clear if the test is testing what it expects to test, but it appears sensitive to minor perturbations.

In my case, I first saw this while modifying the compiler on tip, but it seems to be reproducible manually, including in Go 1.24.

The s slice appears to be stack allocated. Maybe the test does not expect that? Forcing the slices to escape seems to jiggle the test to pass again, at least as observed via a couple of runs (see playground link above).

clone I think is a zero capacity slice passed to unsafe.SliceData. I will note that the unsafe.SliceData doc says:

SliceData returns a pointer to the underlying array of the argument slice.

- If cap(slice) > 0, SliceData returns &slice[:1][0].
- If slice == nil, SliceData returns nil.
- Otherwise, SliceData returns a non-nil pointer to an unspecified memory address.

Comment From: gabyhelp

Related Code Changes

• slices: prevent Clone keeping alive the array when cloning empty slices

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}