gproc: dialyzer unmatched returns (and others) #5

Closed
norton opened this Issue Mar 28, 2011 · 1 comment

Projects

None yet

2 participants

@norton
Contributor
norton commented Mar 28, 2011

I recently started to use dialyzer's unmatched returns feature. There are a number of warnings reported for gproc. I expect this is not an urgent issue. However, I wanted to raise an issue for tracking purposes.

$ dialyzer --plt $(PLT) -Wunmatched_returns -r ./lib

gproc.erl:125: Expression produces a value of type atom() | tid(), but this value is unmatched
gproc.erl:320: Expression produces a value of type 'false' | 'ignore' | integer(), but this value is unmatched
gproc.erl:820: Expression produces a value of type 'ok' | reference(), but this value is unmatched
gproc.erl:896: Expression produces a value of type 'ok' | non_neg_integer(), but this value is unmatched
gproc.erl:1025: Expression produces a value of type [reference()], but this value is unmatched
gproc.erl:1331: The variable _ can never match since previous clauses completely covered the type 'false'
gproc.erl:1332: The variable _ can never match since previous clauses completely covered the type 'false'
gproc.erl:1333: The variable _ can never match since previous clauses completely covered the type 'false'
gproc.erl:1334: The variable _ can never match since previous clauses completely covered the type 'false'
gproc.erl:1339: The variable _ can never match since previous clauses completely covered the type 'false'
gproc.erl:1341: The variable _ can never match since previous clauses completely covered the type 'false'
gproc.erl:1342: The variable _ can never match since previous clauses completely covered the type 'false'
gproc.erl:1343: The variable _ can never match since previous clauses completely covered the type 'false'
gproc.erl:1357: The variable _ can never match since previous clauses completely covered the type 'false'
gproc.erl:1358: The variable _ can never match since previous clauses completely covered the type 'false'
gproc.erl:1369: The variable _ can never match since previous clauses completely covered the type 'false'
gproc.erl:1378: The variable _ can never match since previous clauses completely covered the type 'false'
gproc.erl:1381: The variable _ can never match since previous clauses completely covered the type 'false'
gproc.erl:1388: The variable _ can never match since previous clauses completely covered the type 'false'
gproc.erl:1389: The variable _ can never match since previous clauses completely covered the type 'false'
gproc.erl:1394: The variable _ can never match since previous clauses completely covered the type 'false'
gproc.erl:1401: The variable _ can never match since previous clauses completely covered the type 'false'
gproc.erl:1410: The variable _ can never match since previous clauses completely covered the type 'false'
gproc.erl:1416: The variable _ can never match since previous clauses completely covered the type 'false'
gproc_dist.erl:186: Expression produces a value of type 'ok' | reference(), but this value is unmatched
gproc_init.erl:41: Expression produces a value of type ['true'], but this value is unmatched
gproc_init.erl:45: Expression produces a value of type ['true'], but this value is unmatched
gproc_lib.erl:85: Expression produces a value of type 'ok' | reference(), but this value is unmatched
gproc_lib.erl:101: Expression produces a value of type 'ok' | reference(), but this value is unmatched
gproc_lib.erl:132: Expression produces a value of type 'ok' | reference(), but this value is unmatched
gproc_lib.erl:137: Expression produces a value of type 'ok' | reference(), but this value is unmatched
gproc_lib.erl:157: Expression produces a value of type ['true'], but this value is unmatched

@norton
Contributor
norton commented May 11, 2011

I made several changes to fix the unmatched returns warnings with the latest code in my dev branch (https://github.com/norton/gproc/tree/dev).

norton/gproc@a24e6b2

@uwiger uwiger closed this May 24, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment