Dan Scales 06a43e4ab6 cmd/compile: fix case for structural types where we should be looking at typeparams ...

In getInstantiation, we were not computing tparams correctly for the
case where the receiver of a method was a fully-instantiated type. This
wasn't affecting later parts of the function, since method
instantiations of fully-instantiated types were already being calculated
in an earlier path. But it did give us a non-typeparam when trying to
see if a shape was associated with a type param with a structural type.
The fix is just to get the typeparams associated with the base generic
type. Then we can eliminate a conditional check later in the code.
The tparam parameter of Shapify should always be non-nil

Fixes #51367

Change-Id: I6f95fe603886148b2dad0c581416c51373c85009
Reviewed-on: https://go-review.googlesource.com/c/go/+/388116
Trust: Dan Scales <danscales@google.com>
Run-TryBot: Dan Scales <danscales@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>

2022-02-28 15:58:07 +00:00

..

a.go

cmd/compile: fix case for structural types where we should be looking at typeparams

2022-02-28 15:58:07 +00:00

main.go

cmd/compile: fix case for structural types where we should be looking at typeparams

2022-02-28 15:58:07 +00:00