The Dialyzer is a static analysis tool that identifies software
discrepancies such as definite type errors, code which has become
dead or unreachable due to some programming error, unnecessary
tests, etc. in single Erlang modules or entire (sets of)
applications. Dialyzer starts its analysis from either
debug-compiled BEAM bytecode or from Erlang source code. The file
and line number of a discrepancy is reported along with an
indication of what the discrepancy is about. Dialyzer bases its
analysis on the concept of success typings which allows for sound
warnings (no false positives).
Read more about Dialyzer and about how to use it from the GUI
in Dialyzer User's
Guide.
Using the Dialyzer from the command line
Dialyzer also has a command line version for automated use. Below is a
brief description of the list of its options. The same information can
be obtained by writing
in a shell. Please refer to the GUI description for more details on
the operation of Dialyzer.
The exit status of the command line version is:
Usage:
Options:
(or )
- use Dialyzer from the command line (no GUI) to detect defects in the
specified applications (directories or or files)
- same as only that directories are searched recursively for
subdirectories containing or files (depending on the
type of analysis)
(or )
- when using Dialyzer from the command line, send the analysis
results in the specified rather than in stdout
- override the default, which is to analyze debug compiled BEAM
bytecode, and analyze starting from Erlang source code instead
- When using Dialyzer from the command line, output the raw analysis
results (Erlang terms) instead of the formatted result.
The raw format is easier to post-process (for instance, to filter
warnings or to output HTML pages).
(or )
- when analyzing from source, pass the define to Dialyzer (**)
- when analyzing from source, pass the to Dialyzer (**)
- Include in the path for Erlang. Useful when analyzing files
that have directives.
- Store the PLT at the specified location after building it.
- Use the specified plt as the initial persistent lookup table.
- a family of option which selectively turn on/off warnings.
(for help on the names of warnings use )
- do not disable the Erlang shell while running the GUI
- prints the Dialyzer version and some more information and exits
- prints this message and exits
- makes Dialyzer a bit more quiet
- makes Dialyzer a bit more verbose
- Only checks if the initial PLT is up to date and rebuilds it if this is not the case
- Skip the PLT integrity check when running Dialyzer.
Useful when working with installed PLTs that never change.
- The analysis starts from an empty PLT and creates a new one from
the files specified with -c and -r. Only works for beam files.
Use --plt or --output_plt to override the default PLT location.
- The PLT is extended to also include the files specified with
-c and -r. Use --plt to specify which PLT to start from, and --output_plt
to specify where to put the PLT. Note that the analysis might include
files from the PLT if they depend on the new files.
This option only works with beam files.
- The information from the files specified with -c and -r is removed
from the PLT. Note that this may cause a re-analysis of the remaining
dependent files.
- Makes Dialyzer emit warnings even when manipulating the PLT. Only
emits warnings for files that are actually analyzed. The default is to
not emit any warnings when manipulating the PLT. This option has no
effect when performing a normal analysis.
* denotes that multiple occurrences of these options are possible.
** options and work both from command-line and in the Dialyzer GUI;
the syntax of defines and includes is the same as that used by .
Warning options:
- Suppress warnings for functions of no return.
- Suppress warnings for unused functions.
- Suppress warnings for construction of improper lists.
- Suppress warnings for fun applications that will fail.
- Suppress warnings for patterns that are unused or cannot
match.
- Suppress warnings for violations of opaqueness of data types.
***
- Include warnings for functions that only return by means of an
exception.
***
- Include warnings for possible race conditions.
***
- Include warnings about behaviour callbacks which drift from the
published recommended interfaces.
***
- Include warnings for function calls which ignore a structured return
value or do not match against one of many possible return value(s).
***
- Warn about underspecified functions
(the -spec is strictly more allowing than the success typing)
***
- Warn about overspecified functions
(the -spec is strictly less allowing than the success typing)
***
- Warn when the -spec is different than the success typing
*** These are options that turn on warnings rather than
turning them off.