golang.org/x/tools/go/analysis/passes/nilness - The precision can be improved by propagating that the post condition of [reaching the next instruction after] a SliceToArrayPointer is non-nil if the array type has length >= 1 and if it is 0, the nilness of the instruction follows the nilness of the operand.

Caveat: The bit in [] is that otherwise the SliceToArrayPointer instruction panic'd. I don't think this instruction can be referred to if a panic happened so I think this is an always okay interpretation. (Needs some thought. I doubt this is a serious concern for the checker though.)

For the (indirect through x/tools/go/pointer) packages, no direct modifications are expected to be needed. x/tools/go/pointer just needs to be addressed before these packages are compatible with Go code containing slice to pointer-to-array casts.

@timothy-king For example:

func f() {
	var s []int
	t := (*[0]int)(s)
	println(*t)       // want "nil dereference in load"
	_ = *(*[0]int)(s) // want "nil dereference in load"

	// this operation is panic
	_ = *(*[1]int)(s) // want "nil dereference in load"
}

What should we do with the third conversion which can panic?

What should we do with the third conversion which can panic?

If we know that the input to the cast is nil and the type has length >= 1, we can warn that the cast will always panic due to the nil. If it is not too much work a clearer message than "nil dereference in load" might be nice. Maybe "nil slice being cast to an array of len > 0 will always panic"?

Change https://golang.org/cl/337709 mentions this issue: go/analysis: add slice to array pointer conversion to nilness

Change https://golang.org/cl/338849 mentions this issue: go/callgraph/vta: Support the SliceToArrayPointer instruction.

Change https://golang.org/cl/339890 mentions this issue: go/pointer: Support ssa.SliceToArrayPointer.

Here are some data points on guru

given

package main

import "fmt"

func main() {
	i := 0
	var sl = make([]*int, 12)
	sl[2] = &i
	var a = (*[10]*int)(sl)
	_ = a[2]
	fmt.Println(a[2])
}

inside of a directory named "guru"

while running guru from x/tools @6e9046bfcd341

with go version devel go1.18-a6ff433d6a Thu Aug 26 02:06:43 2021 +0000 darwin/amd64

I get

scott@pavillion 47326 % guru  -scope guru/guru pointsto  guru/guru.go:#119,#123
/Users/scott/Dev/47326/guru/guru.go:10.6-10.9: this *int may not point to anything.
scott@pavillion 47326 % guru  -scope guru/guru pointsto  guru/guru.go:#78,#83
/Users/scott/Dev/47326/guru/guru.go:8.2-8.6: this *int may point to these objects:
/Users/scott/Dev/47326/guru/guru.go:6:2: 	I

So it does not quite work right (#119,#123 refers to 'a[2]', #78,#83 refers to 'sl[2]')

Looking at the guru code, it does not seem to need to treat *ssa.SliceToArrayPointer explicitly, it seems the problem is elsewhere.

Change https://go.dev/cl/403354 mentions this issue: guru: Add a TODO list to the guru cmd.