Specs of reltool
Kostis Sagonas
kostis@REDACTED
Fri Oct 15 00:08:36 CEST 2010
A dialyzer user complained that he gets spurious warnings when using
reltool functions. A quick dialyzer run revealed that reltool is full
of erroneous specs which cannot possibly be right.
For example, dialyzer complains that:
reltool.erl:178: The specification for reltool:get_target_spec/1 states
that the function might also return
{'ok',[[any()] | {_,_} | {_,_,_} | {_,_,_,_}] |
{'copy_file',[any()]} | {'strip_beam_file',[any()]} |
{'copy_file',[any()],[any()]} | {'create_dir',[any()],[any()]} |
{'write_file',[any()],maybe_improper_list(any(),binary() | [])} |
{'archive',[any()],[any()],[any()]} |
{'create_dir',[any()],[any()],[any()]}}
but the inferred return is
{'error',string()} | {'ok',pid()}
and indeed:
get_target_spec(PidOrOptions)
when is_pid(PidOrOptions); is_list(PidOrOptions) ->
eval_server(PidOrOptions, true,
fun(Pid) -> reltool_server:gen_spec(Pid) end).
where there is a promise that eval_server/3 will return:
-spec eval_server(server(), boolean(), fun((server_pid()) -> term())) ->
{ok, server_pid()} | {error, reason()}.
These two together cannot be right. In fact, it's easy to see that this
function returns whatever the fun in its third argument returns (which
is term() in this case, if one believes the 3rd argument).
In general, reltool produces many dialyzer warnings of similar kind.
They should be fixed because they are not only wrong, but they affect
users of this application.
Kostis
More information about the erlang-bugs
mailing list