Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

go/types, types2: type checker does not allow to use receive operation even all types in type list are channels #43671

Closed
tdakkota opened this issue Jan 13, 2021 · 8 comments
Closed

go/types, types2: type checker does not allow to use receive operation even all types in type list are channels #43671

tdakkota opened this issue Jan 13, 2021 · 8 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Milestone
Go1.18

Comments

@tdakkota
Copy link

What version of Go are you using (go version)?

$ go version
go version devel +f065ff221b Tue Jan 12 15:56:55 2021 -0800 windows/amd64

Does this issue reproduce with the latest release?

n/a

What operating system and processor architecture are you using (go env)?

  • windows/amd64
  • go2go playground

What did you do?

https://go2goplay.golang.org/p/4ERkDYXAVM-
Also, I got same result from dev.typeparams typechecker using

$ go tool compile -G ./example.go

The problem is here

go/src/cmd/compile/internal/types2/expr.go

Lines 156 to 172 in f065ff2

case syntax.Recv:
typ := x.typ.Chan()
if typ == nil {
check.invalidOpf(x, "cannot receive from non-channel %s", x)
x.mode = invalid
return
}
if typ.dir == SendOnly {
check.invalidOpf(x, "cannot receive from send-only channel %s", x)
x.mode = invalid
return
}
x.mode = commaok
x.typ = typ.elem
check.hasCallOrRecv = true
return
}

x.typ.Chan() returns nil if x.typ is a *TypeParam.

What did you expect to see?

Successful type-check or a stub error like generic slice expressions not yet implemented. All types in RecvChan[T] type list support receive operation.

What did you see instead?

An error

invalid operation: cannot receive from non-channel ch (variable of type parameter type C)
@tdakkota
Copy link
Author

CC @griesemer

@griesemer griesemer self-assigned this Jan 13, 2021
@griesemer griesemer added this to the Go1.17 milestone Jan 13, 2021
@griesemer griesemer added the NeedsFix The path to resolution is known, but the work has not been done. label Jan 13, 2021
@griesemer
Copy link
Contributor

This has not yet been implemented.

@griesemer griesemer changed the title dev.typeparams: type checker does not allow to use receive operation even all types in type list are channels go/types, types2: type checker does not allow to use receive operation even all types in type list are channels Mar 3, 2021
@griesemer griesemer modified the milestones: Go1.17, Go1.18 Apr 14, 2021
@rogpeppe
Copy link
Contributor

I was about to file an issue about this when I found this one.

I'll also mention that type inference doesn't work when the type parameters are omitted from Recv, but I don't see any particular reason why it shouldn't.

@griesemer griesemer mentioned this issue May 3, 2021
Closed
@griesemer
Copy link
Contributor

@rogpeppe Type inference does work if you remove one of the channel types from RecvChan. That is because constraint type inference requires exactly one type in the type list/set. Channels with channel directions are a bit special; they may need some special treatment. I filed a separate issue (#45920).

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/333709 mentions this issue: [dev.typeparams] cmd/compile/internal/types2: implement <-ch where ch is of type parameter type

@griesemer griesemer mentioned this issue Jul 10, 2021
Closed
gopherbot pushed a commit that referenced this issue Jul 14, 2021
@griesemer
[dev.typeparams] cmd/compile/internal/types2: implement <-ch where ch…
ff33d3d 
… is of type parameter type

For #43671

Change-Id: I7db4b3886fab44ec0de7c0935e0ab21c26e3335c
Reviewed-on: https://go-review.googlesource.com/c/go/+/333709
Trust: Robert Griesemer <gri@golang.org>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Findley <rfindley@google.com>
@gopherbot
Copy link
Contributor

Change https://golang.org/cl/335076 mentions this issue: [dev.typeparams] go/types: implement <-ch where ch is of type parameter type

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/335075 mentions this issue: [dev.typeparams] go/types: implement <-ch where ch is of type parameter type

gopherbot pushed a commit that referenced this issue Jul 19, 2021
@findleyr
[dev.typeparams] go/types: implement <-ch where ch is of type paramet…
d6d7f84 
…er type

This is a port of CL 333709 to go/types, adjusted for the different
error API.

Fixes #43671

Change-Id: Ifd340149bfbcabe401cec74398cb83f2ae812e51
Reviewed-on: https://go-review.googlesource.com/c/go/+/335075
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
gopherbot pushed a commit that referenced this issue Jul 19, 2021
@findleyr
[dev.typeparams] go/types: implement ch <- x where ch is of type para…
19b4142 
…meter type

This is a port of CL 333712 to go/types, adjusted for the different
error reporting API and to position errors on the arrows.

Fixes #43671

Change-Id: I7d2de249e86d272c89a046f60e632e75848ff865
Reviewed-on: https://go-review.googlesource.com/c/go/+/335076
Trust: Robert Findley <rfindley@google.com>
Run-TryBot: Robert Findley <rfindley@google.com>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
@griesemer
Copy link
Contributor

This was fixed with the above CLs.

@golang golang locked and limited conversation to collaborators Jun 23, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Milestone
Go1.18
Development

No branches or pull requests
4 participants
@rogpeppe @griesemer @gopherbot @tdakkota