[ASIDE: Please do not reply with top postings.]
On 06/24/2014 05:58 PM, Paulo F. Oliveira wrote:
> Hi.
>> I'm applying dialyzer to my project and still have a bunch of warnings
> whose origin I can't seem to figure out.
>> Unknown functions:
> cover:compile_beam/1
> cover:compile_beam/2
> cover:compile_module/2
> cover:export/2
> cover:get_term/1
> cover:import/1
> cover:is_compiled/1
> cover:module_info/1
> cover:write/2
> eprof:analyze/1
> eprof:log/1
> eprof:start/0
> eprof:start_profiling/1
> eprof:stop_profiling/0
> packages:last/1
> packages:strip_last/1
> xref:add_application/3
> xref:analyze/2
> xref:set_default/3
> xref:set_library_path/2
> xref:start/2
> xref:stop/1
> Unknown types:
> ...
>> I'm using the following to generate the PLT:
>> dialyzer --build_plt --verbose --statistics -Wunmatched_returns
> -Werror_handling -Wrace_conditions -Wunderspecs -Woverspecs -Wspecdiffs
> -r deps --apps ebin asn1 compiler crypto erts hipe inets kernel
> public_key runtime_tools sasl ssl stdlib syntax_tools xmerl edoc eunit
> gs mnesia -I include
>> Does anybody know how to solve this (I don't want to ignore the
> warnings) or could probably point me in the right direction so that I
> can figure it out?
There are various issues in what you do.
First of all, you have to understand what a PLT is. It stands for
Persistent Lookup Table and is a file that is used to cache information
about functions (mainly their types) you do not want to analyze again
and again. In most cases, these are Erlang/OTP libraries and other
applications that your application depends on but you take "as is" (i.e.
you do not control or can modify them). So this PLT you ideally build
only once and forget about it until you update your Erlang/OTP.
It typically does not make much sense to add -W* (warning) options when
you build this PLT. Remember that this is the part of the code that you
do not control or intend to modify. So asking dialyzer for the warnings
of this code base might indeed give you some information about its
quality but will not improve the quality of your PLT.
So in your case I would start with a command of the form:
dialyzer --build_plt -r deps --apps erts kernel stdlib
(Add --statistics to the above for more information about the size of
the analyzed code and the time of the main passes of Dialyzer if you are
interested in seeing this.) This will build a PLT.
What _can_ improve the PLT's quality is to pay attention whether there
are any _important_ unknown functions, and this is why dialyzer informs
you about them. Note that these are not warnings, but instead just an
indication that the information that the analysis has computed may not
be as strong as it would have been if you supplied the analysis with the
missing functions/modules. So, you probably want to also include these
modules in your PLT. Note that you do not have to rebuild one from
scratch. Dialyzer will incrementally refine the analysis results if you
supply the missing modules/libraries:
dialyzer --add_to_plt path/to/missing_module.beam
Now, having built a PLT that you are happy with, you can now analyze
your own code:
dialyzer -r ebin -Wunmatched_returns ... perhaps other -W options here
and keep doing only this step from now on.
Hope this helps,
Kostis