]> Cypherpunks repositories - gostls13.git/commit
cmd/compile: fix case for structural types where we should be looking at typeparams
authorDan Scales <danscales@google.com>
Fri, 25 Feb 2022 22:56:04 +0000 (14:56 -0800)
committerDan Scales <danscales@google.com>
Mon, 28 Feb 2022 15:58:07 +0000 (15:58 +0000)
commit06a43e4ab62bc5f8353e1c6ed5267d51ce2b483c
tree123930505094582ef2927245b558864293a4252e
parent0907d57abf34e1d11debef2ea7bb4d7b2c11f51e
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>
src/cmd/compile/internal/noder/stencil.go
src/cmd/compile/internal/typecheck/subr.go
test/typeparam/issue51367.dir/a.go [new file with mode: 0644]
test/typeparam/issue51367.dir/main.go [new file with mode: 0644]
test/typeparam/issue51367.go [new file with mode: 0644]