This is a follow up on #21738. In https://play.golang.org/p/1EnY2XsjDU:

package main

type E struct{ f int }
type T struct{ E }

func (*T) f() int { return 0 }

type P *T

func main() {
	var x P
	_ = x.f
	_ = (*x).f

	_ = (x.f)() // ERROR: cannot call non-function x.E.f (type int)
	_ = ((*x).f)()
}

x.f is valid only if (*x).f is a valid selector and f resolves to a field (rule 3 in https://tip.golang.org/ref/spec#Selectors. Specifically, x.f and (*x).f denote the same field.

However, cmd/compile appears to refer to the embedded field f in x.f and to the method f in (*x).f.

The selector resolution is inconsistent here. Furthermore, x.f should be disallowed per rule 3 mentioned above. It appears that cmd/compile uses different lookup rules depending on use case: If the type of x is a named pointer type, it ignores methods.

go/types correctly rejects x.f.