Closed dolmen closed 7 years ago
Nice find, thanks for the report.
(Note to self: To fix ineffassign, I would conservatively mark any variable that is the target of a slice operation as "escaping" (meaning it should never be reported as an ineffectual assignment). This could end up silencing some true positives, but I suspect not many.)
I think that the case to consider here is that any array variable from which a slice is built will escape analysis from that point. Because the array data may be modified directly via the array but also through the slice (or through any other slice derived from that slice, or any function that takes the slice as a parameter).
This is in fact the same case of escape as with pointers:
package main
func main() {
var i int
p := &i
f(p)
i = 0
f(p)
var arr [1]int
s := arr[:]
g(s)
arr = [1]int{}
g(s)
}
func f(*int) {}
func g([]int) {}
f
can modify i
through p
, so as soon as a pointer to i
is taken, i
can't be statically tracked.
g
can modify arr
through s
, so as soon as a slice to arr
is taken, arr
can't be statically tracked.
This program triggers a false positive reported by ineffassign:
main.go:9:3: ineffectual assignment to iv
.iv
andivSlice
point to the same data so this is not a ineffective assignment.