[erlang-questions] Dialyzer: Unknown functions

[Kostis Sagonas]

   [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