Receiving from channel is mistakenly checked #167
Labels
needs triaging
Requires triaging by the maintainers
Comments
yuxincs
added a commit
that referenced
this issue
Feb 2, 2024
See issue #192 for a more detailed discussion on handling channels in NilAway. To make this PR more self-contained, below is a partial copy of the discussion there: See the following behaviors regarding nil / closed channels (taken from [this SO post](https://stackoverflow.com/questions/43616434/closed-channel-vs-nil-channel), slightly modified): > 1. A send to a nil channel blocks forever > 2. A receive from a nil channel blocks forever > 3. A send to a closed channel panics > 4. A receive from a closed channel returns the zero value immediately Only case 3 (sending to a closed channel) will result in a panic. The other cases arguably may not be within scope of NilAway's analysis. Moreover, NilAway currently only tracks nilabilities of channels, but not the states of them, making it unable to really handle case 2 and 4. Since this introduces a lot more FPs than TPs (if any), this PR removes logic to require sending to/receiving from nonnil channels. We leave properly handling channels as future work (especially around tracking states of channels). The test cases have been updated to reflect this. Specifically, we kept the test cases there to now serve as negative cases in case for future development of such a support. Fixes #98 Fixes #167 --------- Co-authored-by: Sonal Mahajan <101232472+sonalmahajan15@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
as the spec says "Receiving from a nil channel blocks forever." https://go.dev/ref/spec#Receive_operator
But in code we treat it as panic
https://github.com/uber-go/nilaway/blob/2f6a74d7c0e26d87215dfbda2c9ab5acbb64b11c/assertion/function/assertiontree/root_assertion_node.go#L812C1-L813C1
This solves #98
The text was updated successfully, but these errors were encountered: