[erlang-bugs] Dialyzer v2.2.0 crash
Kostis Sagonas
kostis@REDACTED
Sun May 1 17:53:51 CEST 2011
Peer Stritzinger wrote:
> On Sun, May 1, 2011 at 4:49 PM, Kostis Sagonas <kostis@REDACTED> wrote:
>> Peer Stritzinger wrote:
>
> BTW: is it normal not to get any warnings when just doing --annotate
> in typer and then dialyzer with no manually tweaked spec's
Yes. In fact, typer is just a front end for dialyzer's basic type
inference (i.e. without the warning identification component).
IMO, there is very little point in doing this if you do not intend to
manually "massage" the specs that you get and provide more info for some
of them. Take a look at your previous program. The fact that the two
<<_:64,_:_*8>> types were referring to the same quantity could be
expressed better if you introduced a type as in:
-type packet() :: <<_:64,_:_*8>>,
Similarly for channel:
-type channel() :: atom() | pid() |{atom(),_}.
and then the spec would already look better. Also, dialyzer/typer has
no info on what type of fun you intend to use in the second argument of
function recv/3 but you do! From the code it is clear that it takes
#can_pkt{} record, so why don't you add appropriate types to its fields
and introduce a type for it?
-record(can_pkt, {id :: id(), data :: binary(), timestamp :: ts()}).
-type can_pkt() :: #can_pkt{}.
then the specs can look much better:
-spec recv(packet(), fun((can_pkt()) -> R), channel()) -> R.
-spec decode(packet()) -> can_pkt().
and note that I've used a placeholder type variable R to denote the fact
that function recv/2 returns whatever type the fun in its second
argument returns. You probably know what this type is so you should also
introduce a type for it and use its proper name.
Hope this helps,
Kostis
PS. It's a pity you posted this in erlang-bugs as the information
contained in the above is IMO more interesting than the actual bug.
More information about the erlang-bugs
mailing list