CL 116255 added an extra message to type assertion failures, so that under certain conditions they look like:

panic: interface conversion: interface {} is modfetch.cachedInfo, not modfetch.cachedInfo (types from different packages)

This confused me for a little while: I am working in golang.org/x/vgo/vendor/cmd/go/internal/modfetch and the only other modfetch that seemed plausible would be the cmd/go/internal/modfetch from the standard library. For a minute I wondered how the build could possibly have crossed the two package trees. But in fact in my crash the types in question are from the same package: the message is incorrect. I had originally declared the same type in two functions, and then when I realized one might leak into the other, I made a global, but I forgot to delete one of the function-scoped types.

Here is an equivalent reproduction case:

$ cat /tmp/x.go
package main

var X interface{}

type T struct{}

func F() {
	type T struct{}
	X = T{}
}

func G() {
	type T struct{}
	_ = X.(T)
}

func main() {
	F()
	G()
}
$ go run /tmp/x.go
panic: interface conversion: interface {} is main.T, not main.T (types from different packages)

goroutine 1 [running]:
main.G()
	/tmp/x.go:14 +0x54
main.main()
	/tmp/x.go:19 +0x25
exit status 2
$ 

Can we do something in the check to detect types from the same package but different scopes and change the message to "types from different scopes"? I suppose we could fall back to "types from different scopes or packages" but it would be more helpful if the message can be precise (without being incorrect).

The global type T is unused in the test program, but you could delete either the one in F or the one in G and have a perhaps different test case also worth checking.

/cc @griesemer @randall77