cmd/compile: generic method values behave differently than specific ones

[mdempsky]

https://go.dev/play/p/zU0yk_nHw0_w

The above test program demonstrates the semantics of var t T; _ = t.M where T is either a type alias of one of a few types (I, struct { I }, or struct { *X }); or it's a type parameter instantiated as that same type.

I think the intended spec semantics are that the corresponding specific and generic cases should always match.

Further, under the interpretation in #6475 (comment), I believe that all cases should panic.

/cc @griesemer @ianlancetaylor for confirming expected behavior

[go101]

The promoted method evaluation timing rules need rethought.
I still agree with @ianlancetaylor and think the evaluation should not happen at compile time. to lower doc explanation difficulties and runtime implementation difficulties.

BTW, no matter which way is chosen, this issue is absolutely a SERIOUS bug and should be fixed as earlier as possible.

[mdempsky]

For the record, the other interpretation that I think is reasonable (and somewhat more closely explains the existing implemented semantics) is type parameters act like interfaces, but their dynamic type is always the type argument.

For example, changing var t T in the non-generic function literals to var t I = *new(T) matches when the generic functions panic: https://go.dev/play/p/igIVdyosrZC