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.

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

cmd/compile: Go 1.18 (types2 typechecker) doesn't report "channel element type too large" #49771

danscales opened this issue Nov 24, 2021 · 2 comments


Copy link

@danscales danscales commented Nov 24, 2021

One error message that we are not reporting in Go 1.18 is at least one kind of "channel too large" error. In particular, see test/fixedbugs/issue42058a.go and test/fixedbugs/issue42058b.go. In Go 1.17 or -G=0 mode, we give errors like:

fixedbugs/issue42058a.go:9:7: channel element type too large (>64kB)
fixedbugs/issue42058a.go:13:7: channel element type too large (>64kB)

but no errors in Go1.18 default mode (which is why those tests are currently disabled in run.go). This is for statically declared channels whose element are too large.

Looks like there is a separate just-reported issue #49767 for Go 1.17.2 and Go 1.18 that causes a compiler crash when a channel with a too-large element size is created via make and a channel type literal.

@griesemer @findleyr

Definitely fine for after beta1.

@danscales danscales added this to the Go1.18 milestone Nov 24, 2021
@griesemer griesemer self-assigned this Nov 24, 2021
Copy link

@mengzhuo mengzhuo commented Nov 26, 2021

@griesemer this may help you debug this issue
on the tips

The nod of CHANARGS is nil which causing an internal error "bad type [65536]byte".


Copy link

@griesemer griesemer commented Nov 29, 2021

@danscales This is really a compiler/runtime specific error. There's several ways how this could be fixed:

  1. The type checker (types2) could have additional configuration information such as max. channel size and use it to report an error if necessary.
  2. The type checker is provided a size computation function by the compiler that may return an error as needed. This would be a variant of option 1.
  3. The compiler (noder) could do the type specific check instead.

At the moment I lean towards option 3 because the type-checker doesn't really care for type-checking and certainly couldn't hardwire the limit.


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants