[erlang-bugs] dialyzer: Issues with opaque types

Jean-Sébastien Pédron <>
Fri Nov 30 10:13:02 CET 2012


Hi!

I posted a message on erlang-questions@ a week ago about a warning
reported by Dialyzer:
http://erlang.org/pipermail/erlang-questions/2012-November/070757.html

Ignore the test programs in this previous mail, I narrowed the issue
down a bit.

I had a look at dialyzer_dataflow.erl and I suspect that "opaque" types
are not handled properly. However, I'm not able to understand what the
problem(s) could be.

I attached 3 test programs to this mail (tested with R15B02 and Git
revision d30cee99):

    o  test1_work.erl passes dialyzer checks. The record #state{} is
       declared as a public type (-type) called state().

    o  test1_fail_1.erl doesn't pass dialyzer checks. The record
       #state{} is declared as an opaque type (-opaque) called state().
       The warnings are:
       - The contract test1_fail_1:next_step(#state{},step_fun()) ->
         'ok' cannot be right because the inferred return for
         next_step(State::test1_fail_1:state(),fun((_) -> any())) on
         line 19 is 'ok'
       - Fun application with arguments (State::test1_fail_1:state())
         will fail since the function has type fun(({_,_}) -> {_,_})

    o  test1_fail_2.erl doesn't pass dialyzer checks. The record is
       declared as an opaque type and this type is used in other types &
       specs directives. The warning is:
       - Fun application with arguments (State::test1_fail_2:state())
         will fail since the function has type
         fun((test1_fail_2:state()) -> test1_fail_2:state())

Beside those differences regarding -type/-opaque/-spec, these programs
are exactly the same.

Note that there's a "recursion" in the #state{}/state() and step_fun()
types: the #state{} contains a step_fun() and this step_fun() takes a
#state{} as its argument.

I would expect dialyzer to treat these programs the same. Am I wrong
with my usage of -opaque and state()? Or is this a bug somewhere in
dialyzer?

-- 
Jean-Sébastien Pédron
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test1_work.erl
Type: text/x-erlang
Size: 521 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20121130/2849a93a/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test1_fail_1.erl
Type: text/x-erlang
Size: 523 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20121130/2849a93a/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test1_fail_2.erl
Type: text/x-erlang
Size: 518 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20121130/2849a93a/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20121130/2849a93a/attachment-0003.bin>


More information about the erlang-bugs mailing list