proposal: spec: consider more strict "declared and not used" check (go/vet or even spec)

[griesemer]

The following code

func f(i interface{}) *T {
	x, ok := i.(*T)
	if !ok {
		x := new(T)
		x.f = 0
	}
	return x
}

compiles without errors even though it is obviously incorrect: Inside the block of the if statement, the := operator should have been = instead. The compiler doesn't complain because the assignment to x.f counts as use of x.

Arguably, assignments to fields/elements of composite type variables shouldn't be counted as uses. Their effect is lost if the variable itself is never used and they may hide the fact that the variable is not used.

(This was the underlying cause for #20789.)

[rsc]

Had to pick either spec or cmd/vet for a prefix; picked spec but can still consider vet here.

[alandonovan]

It's surprisingly tricky to detect "weakly used" variables in the general case. In the simple example above, where x is a variable of struct type T and its field f field is not a reference, it suffices to prove that all references to x occur "on the left side" of an assignment. However, this simple check is inadequate for selections that are indirect. If the type of x.f is a pointer or reference, then the sequence of assignments x.f = y; x.f.g = 1 makes x appear to be "weakly used" (that is, only assigned) but it has the additional effect y.g = 1, which could be visible to other functions, as in this example:

type T struct { u *U }
type U struct { i int }

var global = T{u: new(U)}

func f() {
        var t T
        t = global
        t.u.i = 1
}

A sound check strong enough to catch the bug that motivated this proposal would require SSA form and a simple escape analysis, which is more complex than belongs in the language spec, but possibly appropriate for vet.

[mvdan]

Would it be possible to make this a compiler error without including the restriction in the spec? Or is that generally avoided? (This is assuming that when a spec change was mentioned, it would be the compiler enforcing it, not vet)

[alandonovan]

I've sketched a simpler heuristic for vet in https://go-review.googlesource.com/c/47670.

@mvdan Unless a compiler accepts exactly the set of programs the spec requires it to accept, it is implementing a dialect of the language. Dialects cause problems for users because programs that work with one compiler or analysis tool don't work with another.

[gopherbot]

CL https://golang.org/cl/47670 mentions this issue.

[ianlancetaylor]

We can't detect all possible bugs, but if we only count x.f = 1 as an assignment and don't count x.f1.f2 = 1 as one, perhaps we can at least do that.