cmd/vet: warn about using reflect.DeepEqual and == on reflect.Value

[randall77]

This code doesn't do what you think it does:

func f(x, y reflect.Value) bool {
    return reflect.DeepEqual(x, y)
}

It compares the internal details of the two reflect.Value structs, not their contents. The correct code would be reflect.DeepEqual(x.Interface(), y.Interface()).

I don't see any reason why you'd ever want to use DeepEqual on a reflect.Value. Hence no false positives.

If you really wanted to compare two reflect.Values (but you shouldn't), == is equivalent to DeepEqual.

Seems like an easy mistake to make (see #43986 ). Not sure how common it might be, but I suspect it might be common enough to warrant a check.

[randall77]

A few minutes of searching github turned up a few instances.

Both of these look like very confused code, where this vet check might at least point someone in the right direction:

https://github.com/hedzr/assert/blob/e76ed4c3b339a79c3b788bc3fdf4605511203e14/equal.go lines 106-110

https://github.com/cuirixin/phoenix_corelib/blob/fb4035076004c2eca44d4840d390191e052a4d7b/libs/gotransformer/gotransformer_test.go line 19, 37, ...

This one is probably someone who hit this bug, fixed their code, and left a comment about it:

https://github.com/coreos/vcontext/blob/ee043618d38dc1daf804fe352433b5ce2428ea32/validate/validate_test.go lines 212-221

[ianlancetaylor]

Another example (now fixed) at go-openapi/validate#137.

[dominikh]

Related: #18871

[rsc]

Perhaps we should define that when you pass a reflect.Value to DeepEqual, DeepEqual uses that directly instead of calling reflect.ValueOf on it. Then instead of warning about broken code we just make it not broken.

[randall77]

That would work in my example case. Not sure what the right behavior is for, e.g., a struct with a reflect.Value-typed field.

[rsc]

I agree about not applying that to reflect.Value-typed fields, but vet was not going to catch those either.

[rsc]

We have some history here where fmt.Print interprets a reflect.Value by using what it contains.

case reflect.Value:
	// Handle extractable values with special methods
	// since printValue does not handle them at depth 0.
	if f.IsValid() && f.CanInterface() {
		p.arg = f.Interface()
		if p.handleMethods(verb) {
			return
		}
	}
	p.printValue(f, verb, 0)

@ianlancetaylor says he ran into this recently due to a Go 1.16 internal change and it was not at all clear given the call (like in Keith's example at the top) that there was even a problem. So we should do either the vet change or the "make it work" change.

I'm leaning toward "make it work".

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

[rsc]

Does anyone object to just making DeepEqual handle reflect.Value arguments by interpreting what the Values represent?
(That is, it would avoid calling reflect.ValueOf on those arguments and then proceed as before.)

[zigo101]

avoid calling reflect.ValueOf

typo? avoid calling .Interface()?

[zigo101]

Does it apply to reflect.Value values with interfaces as underlying values?
And what about the underlying values of the underlying interface values are also reflect.Value values,
And ...