cmd/compile/internal/types2: slightly relax notion of structural type

If we have all channel types in a constraint, there is no structural type
if they don't all have the same channel direction (and identical element
types, of course). By allowing different channel types for the purposes of
the structural type, as long as there is not a send-only _and_ a receive-
only channel in the type set, we make it possible to find a useful, if
restricted by channel direction, structural type where before there was
none.

So if we have unrestricted and send-only channels, the structural type is
the send-only channel, and vice versa.

For all operations on channels that rely on a structural type, it's always
ok to have an unrestricted channel, so this is not affecting their behavior.
But it makes those operations more flexible in the presence of type parameters
containing mixed channel types.

For constraint type inference, where we currently may not infer a channel
at all, this change allows us to infer a more restricted channel (send- or
receive-only). If the inferred channel type is a valid type argument we win;
if not we haven't lost anything.

Use structuralType for send and receive operations and adjust related
error messages (the error message that change are the ones involving
type parameters, so historic error messages are preserved).

Fixes #45920.

Change-Id: If3a64d29c37e7734d3163df330f8b02dd032bc60
Reviewed-on: https://go-review.googlesource.com/c/go/+/363075
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>

0 files changed, 0 insertions, 0 deletions