/cc @griesemer @findleyr

A variant:

% cat /tmp/x.go
package p

type T interface{ M() }

func F() T

var _ = F().(*X)

type X struct{}
% go tool compile /tmp/x.go
/tmp/x.go:7:9: impossible type assertion: F() (value of type T) (missing method M)
% 

In this case X is defined, and the problem is that *X does not implement the M method.
So it is now correct to print an impossible type assertion message.

But the actual message does not show a type assertion.
It should show F().(*X) instead of just F().

I assume that printing the actual assertion expression will result in

/tmp/x.go:7:12: impossible type assertion: F().(*X) (value of type *X) (missing method M)

That will be confusing too, because it will no longer mention T.
It would probably be better to have:

/tmp/x.go:7:12: impossible type assertion: F().(*X)
	*X does not implement T (missing method M)

The problem seems that with types2, when check.conf.CompilerErrorMessages is set, types2 changes the error message to match the compiler. Thus, the error message now does not contain invalid type, so check.err won't skip it.

But I think the root cause is that the check T == Typ[invalid] will be false if T is a pointer to an invalid type. Maybe we should change all that check to include the pointer elem if T is a pointer. So we can terminate the typecheck earlier.

Maybe we should change all that check to include the pointer elem if T is a pointer. So we can terminate the typecheck earlier.

good idea, @cuonglm !

Change https://golang.org/cl/356449 mentions this issue: cmd/compile, types2: avoid confusing follow-on error in invalid type assertion

Change https://golang.org/cl/356512 mentions this issue: cmd/compile, types2: better error message for invalid type assertion