Navigation Menu

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

Jump to bottom

runtime: chanrecv funcs don't actually use the *chantype parameter #19591

Closed
mvdan opened this issue Mar 17, 2017 · 7 comments
Closed

runtime: chanrecv funcs don't actually use the *chantype parameter #19591

mvdan opened this issue Mar 17, 2017 · 7 comments
Labels
FrozenDueToAge
Milestone
Go1.9

Comments

@mvdan
Copy link
Member

mvdan commented Mar 17, 2017 

func chanrecv(t *chantype, c *hchan, ep unsafe.Pointer, block bool) (selected, received bool)

The t *chantype parameter isn't actually used. I assume it could be removed, but the entry point magic scares me a bit and I don't dare do a CL myself.

Unless the parameter is actually used/needed for a reason that's not obvious given the implementation?

Found with https://github.com/mvdan/unparam.
@mvdan
Copy link
Member Author

mvdan commented Mar 17, 2017

Also worth noting that chansend does use its t *chantype parameter, but only if either raceenabled or msanenabled are true. Would either of those need the type parameter at some point in the future?

@mdempsky
Copy link
Member

mdempsky commented Mar 17, 2017 •
edited

The chantype is stored as a field in the hchan anyway. I think we can get rid of the parameters.

Do you want to send a CL?

@mvdan
Copy link
Member Author

mvdan commented Mar 17, 2017

Sure, I'll get on that.

The chantype is stored as a field in the hchan anyway.

So you mean get rid of it in chansend too?

@mdempsky
Copy link
Member

So you mean get rid of it in chansend too?

Correct.

@mvdan
Copy link
Member Author

mvdan commented Mar 18, 2017

Having some issues with panics, I'm likely missing some change to make the compiler and/or runtime fully aware of the new func signature. I'll post the CL on monday in any case, asking for pointers if I'm still stuck.

@mvdan
Copy link
Member Author

mvdan commented Mar 18, 2017

Ah, found it - a missing mkcall1 tweak in gc.

@gopherbot
Copy link

CL https://golang.org/cl/38351 mentions this issue.

@bradfitz bradfitz added this to the Go1.9 milestone Mar 21, 2017
@golang golang locked and limited conversation to collaborators Mar 21, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Go1.9
Development

No branches or pull requests
4 participants
@bradfitz @mdempsky @mvdan @gopherbot