![[Erlang Systems]](min_head.gif)
xref is a cross reference tool that can be used for
finding dependencies between functions, modules, applications
and releases.
Calls are pairs (From, To) of
functions, modules, applications or releases. From is said to
call To, and To is said to be used by From. Calls between
functions are either local
calls like f(), or external calls like
m:f(). Module data,
which are extracted from BEAM files, include local functions,
exported functions, local calls and external calls. By default,
calls to built-in functions (BIF ) are ignored, but
if the option builtins, accepted by some of this
module´s functions, is set to true, calls to BIFs
are included as well. It is the analyzing OTP version that
decides what functions are BIFs. Functional objects are assumed
to be called where they are created (and nowhere else). Unresolved calls are calls to
apply or spawn with variable module or variable
arguments. Examples are M:F(a), apply(M, f, [a]),
spawn(m, f, Args). The unresolved calls are a
subset of the external calls.
Calls where the function is variable but the module and the
number of arguments are known, are resolved by replacing the
function with the atom '$F_EXPR'.
 |
Unresolved calls make module data incomplete, which implies that the results of analyses may be invalid. |
Applications are collections of modules. The
modules´ BEAM files are located in the ebin
subdirectory of the application directory. The name of the
application directory determines the name and version of the
application.
Releases are collections of applications
located in the lib subdirectory of the release directory.
There is more to read about applications and releases in the
Design Principles book.
Xref servers are identified
by names, supplied when creating new servers. Each xref server
holds a set of releases, a set of applications, and a set of
modules with module data. Xref servers are independent of
each other, and all analyses are evaluated in the context of one
single xref server (exceptions are the functions m/1 and
d/1 which do not use servers at all). The mode of an xref
server determines what module data are extracted from BEAM files
as modules are added to the server.
Starting with R7, BEAM files contain so called debug information, which is an abstract
representation of the code. In functions mode, which is
the default mode, function calls and line numbers are extracted
from debug information. In modules mode, debug
information is ignored if present, but dependencies between
modules are extracted from other parts of the BEAM files.
The modules mode is significantly less time and space
consuming than the functions mode, but the
analyses that can be done are limited.
An analyzed module is a module that has been added to an xref server together with its module data. A library module is a module located in some directory mentioned in the library path. A library module is said to be used if some of its exported functions are used by some analyzed module. An unknown module is a module that is neither an analyzed module nor a library module, but whose exported functions are used by some analyzed module. An unknown function is a used function that is neither local or exported by any analyzed module nor exported by any library module. An undefined function is an externally used function that is not exported by any analyzed module or library module. With this notion, a local function can be an undefined function, namely if it is used externally from some module. All unknown functions are also undefined functions; there is a figure in the User´s Guide that illustrates this relationship.
Before any analysis can take place, module data must be set
up. For instance, the cross reference and the unknown
functions are computed when all module data are known. The
functions that need complete data (analyze, q,
variables) take care of setting up data automatically.
Module data need to be set up (again) after calls to any of the
add, replace, remove,
set_library_path or update functions.
The result of setting up module data is the Call Graph.
A (directed) graph consists of a set of vertices
and a set of (directed) edges. The vertices of the Call Graph
are the functions of all module data: local and exported
functions of analyzed modules; used BIFs; used exported
functions of library modules; and unknown functions.
The functions module_info/0,1 added by the compiler are
included among the exported functions, but only when called
from some module.
The edges are the function calls of all module data. A
consequence of the edges being a set is that there is only one
edge if a function is used locally or externally several times
on one and the same line of code.
The Call Graph is represented by
Erlang terms (the sets are lists), which is suitable for many
analyses. But for analyses that look at chains of calls, a list
representation is much too
slow. Instead the representation offered by the digraph
module is used. The translation of the list representation of
the Call Graph - or a subgraph thereof - to the digraph
representation does not
come for free, so the language used for expressing queries to be
described below has a special operator for this task and a
possibility to save the digraph representation for
subsequent analyses.
In addition to the Call Graph there is a graph called the Inter Call Graph. This is a graph of calls (From, To) such that there is a chain of calls from From to To in the Call Graph, and each of From and To is an exported function or an unused local function. The vertices are the same as for the Call Graph.
Calls between modules, applications and releases are also
directed graphs. The types
of the vertices and edges of these graphs are (ranging from the
most special to the most general):
Fun for functions; Mod for modules;
App for applications; and Rel for releases.
The following paragraphs will describe the different constructs
of the language used for selecting and analyzing parts of the
graphs, beginning with the constants:
: Type | RegExpr
[Constant, ...]
| {Constant, ...}
-> FunSpec
| {MFA, MFA}
| AtomConst -> AtomConst
| {AtomConst, AtomConst}
: Function / Arity
{Module, Function, Arity}
: Type
| RegFunc
| RegFunc : Type
: RegFunction / RegArity
_
_
regexp module, enclosed in double quotes -
Fun | Mod | App | Rel
Examples of constants are: kernel, kernel->stdlib,
[kernel, sasl], [pg -> mnesia, {tv, mnesia}] :
Mod.
It is an error if an instance of Const does not match any
vertex of any graph.
If there are more than one vertex matching an untyped instance
of AtomConst, then the one of the most general type is
chosen.
A list of constants is interpreted as a set of constants, all of
the same type.
A tuple of constants constitute a chain of calls (which may,
but does not have to, correspond to an actual chain of calls of
some graph).
Assigning a type to a list or tuple of Constant is
equivalent to assigning the type to each Constant.
Regular expressions are used as a
means to select some of the vertices of a graph.
A RegExpr consisting of a RegString and a type -
an example is "xref_.*" : Mod - is interpreted as those
modules (or applications or releases, depending on the type)
that match the expression.
Similarly, a RegFunc is interpreted as those vertices
of the Call Graph that match the expression.
An example is "xref_.*":"add_.*"/"(2|3)", which matches
all add functions of arity two or three of any of the
xref modules.
Another example, one that matches all functions of arity 10 or
more: _:_/"[1-9].+". Here _ is an abbreviation for
".*", i.e. the regular expression that matches
everything.
The syntax of variables is simple:
There are two kinds of variables: predefined variables and user
variables.
Predefined variables
hold set up module data, and cannot be assigned to but only used
in queries.
User variables on the other
hand can be assigned to, and are typically used for
temporary results while evaluating a query, and for keeping
results of queries for use in subsequent queries.
The predefined variables are (variables marked with (*) are
available in functions mode only):
E
V
M
A
R
ME
AE
RE
L
X
F
B
B can be non-empty
if builtins is false for all analyzed modules,
namely if there are unresolved calls (some of the
apply and spawn functions are BIFs).
U
UU
XU
LU
LC
XC
AM
UM
LM
UC
EE
These are a few facts about the
predefined variables (the set operators + (union) and
- (difference) as well as the cast operator
(Type) are described below):
F is equal to L + X.
V is equal to X + L + B + U, where X,
L, B and U are pairwise disjoint (that
is, have no elements in common).
UU is equal to V - (XU + LU), where
LU and XU may have elements in common. Put in
another way:
V is equal to UU + XU + LU.
E is equal to LC + XC. Note that LC
and XC may have elements in common, namely if some
function is used locally and externally from one and the same
function.
U is a subset of XU.
B is a subset of XU.
LU is equal to range LC.
XU is equal to range XC.
LU is a subset of F.
UU is a subset of F.
M is equal to AM + LM + UM, where AM,
LM and UM are pairwise disjoint.
ME is equal to (Mod) E.
AE is equal to (App) E.
RE is equal to (Rel) E.
(Mod) V is a subset of M. Equality holds
if all analyzed modules have some local, exported function
or unknown function.
(App) M is a subset of A. Equality holds
if all applications have some module.
(Rel) A is a subset of R. Equality holds
if all releases have some application.
An important notion is that of conversion of expressions. The syntax of a cast expression is:
( Type ) Expression
The interpretation of the cast operator depends on the named
type Type, the type of Expression, and the
structure of the elements of the interpretation of Expression.
If the named type is equal to the
expression type, no conversion is done. Otherwise, the
conversion is done one step at a time;
(Fun) (App) RE, for instance, is equivalent to
(Fun) (Mod) (App) RE. Now assume that the
interpretation of Expression is a set of constants
(functions, modules, applications or releases). If the named
type is more general than the expression type, say Mod
and Fun respectively, then the interpretation of the cast
expression is the set of modules that have at least one
of their functions mentioned in the interpretation of the
expression. If the named
type is more special than the expression type, say Fun
and Mod, then the interpretation is the set of all the
functions of the modules (in modules mode, the conversion
is partial since the local functions are not known).
The conversions to and from applications and releases
work analogously. For instance, (App) "xref_.*" : Mod
returns all applications containing at least one module
such that xref_ is a prefix of the module name.
Now assume that the interpretation of Expression is a
set of calls. If the named type is more general than the
expression type, say Mod and Fun respectively,
then the interpretation of the cast expression is the set of
calls (M1, M2) such that the interpretation of the
expression contains a call from some function
of M1 to some function of M2. If the named type is more special
than the expression type, say Fun and Mod, then
the interpretation is the set of all function calls
(F1, F2) such that the interpretation of the expression
contains a call (M1, M2) and F1 is
a function of M1 and F2 is a function of M2 (in modules
mode, there are no functions calls, so a cast to Fun
always yields an empty set). Again, the conversions to and from
applications and releases work analogously.
The interpretation of constants and variables are sets, and those sets can be used as the basis for forming new sets by the application of set operators. The syntax:
+ | * | -
+, * and - are interpreted as union,
intersection and difference respectively: the union of two sets
contains the elements of both sets; the intersection of two sets
contains the elements common to both sets; and the difference of
two sets contains the elements of the first set that are not
members of the second set. The elements of the two sets must be
of the same structure; for instance, a function call cannot be
combined with a function. But if a cast operator can make the
elements compatible, then the more general elements are
converted to the less general element type. For instance,
M + F is equivalent to
(Fun) M + F, and E - AE
is equivalent to E - (Fun) AE. One more
example: X * xref : Mod is interpreted as the set of
functions exported by the module xref; xref : Mod
is converted to the more special type of X (Fun,
that is) yielding all functions of xref, and the
intersection with X (all functions exported by analyzed
modules and library modules) is interpreted as those functions
that are exported by some module and functions of
xref.
There are also unary set operators:
domain | range | strict
Recall that a call is a pair (From, To). domain
applied to a set of calls is interpreted as the set of all
vertices From, and range as the set of all vertices To.
The interpretation of the strict operator is the operand
with all calls on the form (A, A) removed.
The interpretation of the restriction operators is a subset of the first operand, a set of calls. The second operand, a set of vertices, is converted to the type of the first operand. The syntax of the restriction operators:
|
||
|||
The interpretation in some detail for the three operators:
|
||
|||
CS and all sets of vertices
VS, CS ||| VS is equivalent to
CS | VS * CS || VS.
Two functions (modules,
applications, releases) belong to the same strongly connected
component if they call each other (in)directly. The
interpretation of the components operator is the set of
strongly connected components of a set of calls. The
condensation of a set of calls is a new set of calls
between the strongly connected components such that there is an
edge between two components if there is some constant of the first
component that calls some constant of the second component.
The interpretation of the of operator is a chain of
calls of the second operand (a set of calls) that passes throw
all of the vertices of the first operand (a tuple of
constants), in the given order. The second operand
is converted to the type of the first operand.
For instance, the of operator can be used for finding out
whether a function calls another function indirectly, and the
chain of calls demonstrates how. The syntax of the graph
analyzing operators:
components | condensation | of
As was mentioned before, the graph analyses operate on
the digraph representation of graphs.
By default, the digraph representation is created when
needed (and deleted when no longer used), but it can also be
created explicitly by use of the closure operator:
closure
The interpretation of the closure operator is the
transitive closure of the operand.
The restriction operators are defined for closures as well;
closure E | xref : Mod is
interpreted as the direct or indirect function calls from the
xref module, while the interpretation of
E | xref : Mod is the set of direct
calls from xref.
If some graph is to be used in several graph analyses, it saves
time to assign the digraph representation of the graph
to a user variable,
and then make sure that each graph analysis operates on that
variable instead of the list representation of the graph.
The lines where functions are defined (more precisely: where
the first clause begins) and the lines where functions are used
are available in functions mode. The line numbers refer
to the files where the functions are defined. This holds also for
files included with the -include and -include_lib
directives, which may result in functions defined apparently in
the same line. The line operators are used for assigning
line numbers to functions and for assigning sets of line numbers
to function calls.
The syntax is similar to the one of the cast operator:
( LineOp) Expression
( XLineOp) Expression
Lin | ELin | LLin | XLin
XXL
The interpretation of the Lin operator applied to a set
of functions assigns to each function the line number where the
function is defined. Unknown functions and functions of library
modules are assigned the number 0.
The interpretation of some LineOp operator applied to a set of function calls assigns to each call the set of line numbers where the first function calls the second function. Not all calls are assigned line numbers by all operators:
Lin operator is defined for Call Graph Edges;
LLin operator is defined for Local Calls.
XLin operator is defined for External Calls.
ELin operator is defined for Inter Call Graph Edges.
The Lin (LLin, XLin) operator assigns
the lines where calls (local calls, external calls) are made.
The ELin operator assigns to each call (From, To),
for which it is defined, each line L such that there is
a chain of calls from From to To beginning with a call on line
L.
The XXL operator is defined for the interpretation of
any of the LineOp operators applied to a set of function
calls. The result is that of replacing the function call with
a line numbered function call, that is, each of the two
functions of the call is replaced by a pair of the function and
the line where the function is defined. The effect of the
XXL operator can be undone by the LineOp operators. For
instance, (Lin) (XXL) (Lin) E is
equivalent to (Lin) E.
The +, -, * and # operators are
defined for line number expressions, provided the operands are
compatible. The LineOp operators are also defined for
modules, applications, and releases; the operand is implicitly
converted to functions. Similarly, the cast operator is defined
for the interpretation of the LineOp operators.
The interpretation of the counting
operator is the number of elements of a set. The operator
is undefined for closures. The +, - and *
operators are interpreted as the obvious arithmetical operators
when applied to numbers. The syntax of the counting operator:
#
All binary operators are left associative; for instance,
A | B || C is equivalent to
(A | B) || C. The following is a list
of all operators, in increasing order of precedence:
+, -
*
#
|, ||, |||
of
(Type)
closure, components, condensation,
domain, range, strict
Parentheses are used for grouping, either to make an expression more readable or to override the default precedence of operators:
( Expression )
A query is a non-empty sequence of statements. A statement is either an assignment of a user variable or an expression. The value of an assignment is the value of the right hand side expression. It makes no sense to put a plain expression anywhere else but last in queries. The syntax of queries is summarized by these productions:
, ...
:= Expression
| Variable = Expression
A variable cannot be assigned a new value unless first
removed. Variables assigned to by the = operator are
removed at the end of queries, while variables assigned to by
the := operator can only be removed by calls to
forget.
Types
application() = atom()
arity() = integer()
bool() = true | false
call() = {atom(), atom()} | funcall()
constant() = mfa() | module() | application() | release()
directory() = string()
file() = string()
funcall() = {mfa(), mfa()}
function() = atom()
library() = atom()
library_path() = path() | code_path
mfa() = {module(), function(), arity()}
mode() = functions | modules
module() = atom()
integer() = int() >= 0
release() = atom()
string_position() = integer() | at_end
variable() = atom()
xref() = atom()
m(Module) -> [Result] | Error
m(file()) -> [Result] | Error
Error = {error, module(), Reason}Module = module()Reason = {file_error, file(), error()}
| {interpreted, module()}
| {no_debug_info, file()}
| {no_such_module, module()}
| - error from beam_lib:chunks/2 -
Result = {undefined, [funcall()]} | {unused, [mfa()]}The given BEAM file (with or without the .beam
extension) or the the file found by calling
code:which(Module) is checked for calls to undefined functions
and for unused local functions. The code path is used as
library
path.
Returns a list of tuples, where the first element of each tuple
is one of:
undefined, a sorted list of calls to
undefined functions;
unused, a sorted list of unused local functions.
If the BEAM file contains no debug information, the error
message no_debug_info is returned.
d(directory()) -> [Result] | Error
Error = {error, module(), Reason}Reason = {file_error, file(), error()}
| {unrecognized_file, file()}
| - error from beam_lib:chunks/2 -
Result = {undefined, [funcall()]} | {unused, [mfa()]}The modules found in a directory are checked for calls to undefined functions and for unused local functions. The code path is used as library path. Returns a list of tuples, where the first element of each tuple is one of:
undefined, a sorted list of calls to
undefined functions;
unused, a sorted list of unused local functions.
Only BEAM files that contain debug information are checked.
start(xref() [, Options]) -> Return
Options = [Option] | OptionOption = {xref_mode, mode()} | term()Return = {ok, pid()}
| {error, {already_started, pid()}}
Creates an xref
server. The default mode is functions.
Options that are not recognized by xref
are passed on to gen_server:start/4.
set_default(xref(), Option, Value) -> {ok, OldValue} | Error
set_default(xref(), OptionValues) -> ok | Error
Error = {error, module(), Reason}OptionValues = [OptionValue] | OptionValueOptionValue = {Option, Value}Option = builtins | recurse | verbose | warningsReason = {invalid_options, term()}Value = bool()Sets the default value of one or more options. The options that can be set this way are:
builtins, with initial default value false;
recurse, with initial default value false;
verbose, with initial default value true;
warnings, with initial default value true.
The initial default values are set when creating an xref server.
get_default(xref()) -> [{Option, Value}]
get_default(xref(), Option) -> {ok, Value} | Error
Error = {error, module(), Reason}Option = builtins | recurse | verbose | warningsReason = {invalid_options, term()}Value = bool()Returns the default values of one or more options.
add_release(xref(), directory() [, Options]) ->
{ok, release()} | Error
Error = {error, module(), Reason}Options = [Option] | OptionOption = {builtins, bool()} | {name, release()}
| {verbose, bool()} | {warnings, bool()}Reason =
{application_clash, {application(), directory(), directory()}}
| {file_error, file(), error()}
| {invalid_options, term()}
| {release_clash, {release(), directory(), directory()}}
| - see also add_directory -
Adds a release, the applications of the release, the
modules of the applications, and module data of the
modules to an xref server.
The applications will be members of the release,
and the modules will be members of the applications.
The default is to use the base name of the
directory as release name, but this can be overridden by the
name option. Returns the name of the release.
If the given directory has a subdirectory named lib,
the directories in that directory are assumed to be
application directories, otherwise all subdirectories of the
given directory are assumed to be application directories.
If there are several versions of some application, the one
with the highest version is chosen.
If the mode of the xref
server is functions, BEAM files that contain no
debug information are
ignored.
add_application(xref(), directory() [, Options]) ->
{ok, application()} | Error
Error = {error, module(), Reason}Options = [Option] | OptionOption = {builtins, bool()} | {name, application()}
| {verbose, bool()} | {warnings, bool()}Reason =
{application_clash, {application(), directory(), directory()}}
| {file_error, file(), error()}
| {invalid_options, term()}
| - see also add_directory -
Adds an application, the modules of the application and module data of the
modules to an xref server.
The modules will be members of the application.
The default is to use the base name of the
directory with the version removed as application name, but
this can be overridden by the name option. Returns the
name of the application.
If the given directory has a subdirectory named
ebin, modules (BEAM files) are searched for in that
directory, otherwise modules are searched for in the given
directory.
If the mode of the xref
server is functions, BEAM files that contain no
debug information are
ignored.
add_directory(xref(), directory() [, Options]) ->
{ok, Modules} | Error
Error = {error, module(), Reason}Modules = [module()]Options = [Option] | OptionOption = {builtins, bool()} | {recurse, bool()}
| {verbose, bool()} | {warnings, bool()}Reason = {file_error, file(), error()}
| {invalid_options, term()}
| {unrecognized_file, file()}
| - error from beam_lib:chunks/2 -
Adds the modules found in the given directory and the modules´ data
to an xref server.
The default is not to examine subdirectories, but if the option
recurse has the value true, modules are searched
for in subdirectories on all levels as well as in the given
directory.
Returns a sorted list of the names of the added modules.
The modules added will not be members of any applications.
If the mode of the xref
server is functions, BEAM files that contain no
debug information are
ignored.
add_module(xref(), file() [, Options]) -> {ok, module()} | Error
Error = {error, module(), Reason}Options = [Option] | OptionOption = {builtins, bool()} | {verbose, bool()}
| {warnings, bool()}Reason = {file_error, file(), error()}
| {invalid_options, term()}
| {module_clash, {module(), file(), file()}}
| {no_debug_info, file()}
| - error from beam_lib:chunks/2 -
Adds a module and its module data to an xref server. The module will not be member of any application. Returns the name of the module.
If the mode of the xref
server is functions, and the BEAM file contains no
debug information,
the error message no_debug_info is returned.
replace_application(xref(), application(),
directory() [, Options]) -> {ok, application()} | Error
Error = {error, module(), Reason}Options = [Option] | OptionOption = {builtins, bool()} | {verbose, bool()}
| {warnings, bool()}Reason = {no_such_application, application()}
| - see also add_application -
Replaces the modules of an application with other modules read from an application directory. Release membership of the application is retained. Note that the name of the application is kept; the name of the given directory is not used.
replace_module(xref(), module(), file() [, Options]) ->
{ok, module()} | Error
Error = {error, module(), Reason}Options = [Option] | OptionOption = {verbose, bool()} | {warnings, bool()}ReadModule = module()Reason = {module_mismatch, module(), ReadModule}
| {no_such_module, module()}
| - see also add_module -
Replaces module
data of an analyzed module with
data read from a BEAM file. Application membership of the
module is retained, and so is the value of the
builtins option of the module. An error is returned
if the name of the read module differs from the given
module.
The update function is an alternative for updating
module data of recompiled modules.
remove_release(xref(), release()) -> ok | Error
Error = {error, module(), Reason}Reason = {no_such_release, release()}Removes a release and its applications, modules and module data from an xref server.
remove_application(xref(), application()) -> ok | Error
Error = {error, module(), Reason}Reason = {no_such_application, application()}Removes an application and its modules and module data from an xref server.
remove_module(xref(), module()) -> ok | Error
Error = {error, module(), Reason}Reason = {no_such_module, module()}Removes an analyzed module module and its module data from an xref server.
set_library_path(xref(), library_path() [, Options]) ->
ok | Error
Error = {error, module(), Reason}Options = [Option] | OptionOption = {verbose, bool()}Reason = {invalid_options, term()}
| {invalid_path, term()}
Sets the library path. If the given path is a list of directories, the set of library modules is determined by choosing the first module encountered while traversing the directories in the given order, for those modules that occur in more than one directory. By default, the library path is an empty list.
The library path code_path is
used by the functions
m/1 and d/1, but can also be set explicitly.
Note however that the code path will be traversed once for
each used library
module while setting up module data.
On the other hand, if there are only a few modules that are
used by not analyzed, using code_path may be faster
than setting the library path to code:get_path().
If the library path is set to code_path, the set of
library modules is not determined, and the info
functions will return empty lists of library modules.
get_library_path(xref()) -> {ok, library_path()}
Returns the library path.
info(xref()) -> [Info]
info(xref(), Category) -> [{Item, [Info]}]
info(xref(), Category, Items) ->
[{Item, [Info]}]
Application = [] | [application()]Category = modules | applications | releases | librariesInfo = {application, Application}
| {builtins, bool()}
| {directory, directory()}
| {library_path, library_path()}
| {mode, mode()}
| {no_analyzed_modules, integer()}
| {no_applications, integer()}
| {no_calls, {NoResolved, NoUnresolved}}
| {no_function_calls, {NoLocal, NoResolvedExternal,
NoUnresolved}}
| {no_functions, {NoLocal, NoExternal}}
| {no_inter_function_calls, integer()}
| {no_releases, integer()}
| {release, Release}
| {version, Version}
Item = module() | application() | release() | library()Items = Item | [Item]NoLocal = NoExternal = NoResolvedExternal, NoResolved =
NoUnresolved = integer()Release = [] | [release()]Version = [integer()]
The info functions return information as a list of
pairs {Tag, term()} in some order about the state and the
module data
of an xref server
.
info/1 returns information with the following tags
(tags marked with (*) are available in functions
mode only):
library_path, the library path;
mode, the mode;
no_releases, number of releases;
no_applications, total number of applications
(of all releases);
no_analyzed_modules, total number of analyzed modules;
no_calls (*), total number of calls (in all
modules), regarding instances of one function call in
different lines as separate calls;
no_function_calls (*), total number of local calls, resolved external calls and
unresolved calls;
no_functions (*), total number of local and exported
functions;
no_inter_function_calls (*), total number of
calls of the Inter
Call Graph.
info/2 and info/3 return information about
all or some of the analyzed modules, applications, releases
or library modules of an xref server.
The following information is returned for each analyzed module:
application, an empty list if the module does
not belong to any application, otherwise a list of
the application name;
builtins, whether calls to BIFs are included
in the module´s data;
directory, the directory where the
module´s BEAM file is located;
no_calls (*), number of calls, regarding
instances of one function call in different lines as
separate calls;
no_function_calls (*), number of local
calls, resolved external calls and unresolved calls;
no_functions (*), number of local and exported
functions;
no_inter_function_calls (*), number of calls
of the Inter Call Graph;
The following information is returned for each application:
directory, the directory where the
modules´ BEAM files are located;
no_analyzed_modules, number of analyzed
modules;
no_calls (*), number of calls of the
application´s modules, regarding instances of
one function call in different lines as separate calls;
no_function_calls (*), number of local
calls, resolved external calls and unresolved calls of the
application´s modules;
no_functions (*), number of local and exported
functions of the application´s modules;
no_inter_function_calls (*), number of calls
of the Inter Call Graph of the
application´s modules;
release, an empty list if the application does not
belong to any release, otherwise a list of the release name;
version, the application´s version as
a list of numbers. For instance, the directory "kernel-2.6"
results in the application name kernel and the
application version [2,6]; "kernel" yields the name
kernel and the version [].
The following information is returned for each release:
directory, the release directory;
no_analyzed_modules, number of analyzed
modules;
no_applications, number of applications;
no_calls (*), number of calls of the
release´s modules, regarding
instances of one function call in different lines as
separate calls;
no_function_calls (*), number of local
calls, resolved external calls and unresolved
calls of the release´s modules;
no_functions (*), number of local and exported
functions of the release´s modules;
no_inter_function_calls (*), number of calls
of the Inter Call Graph of the release´s modules.
The following information is returned for each library module:
directory, the directory where the library
module´s BEAM file is located.
For each number of calls, functions etc. returned by the
no_ tags, there is a query returning the same number.
Listed below are examples of such queries. Some of the
queries return the sum of a two or more of the no_
tags numbers. mod (app, rel) refers to
any module (application, release).
no_analyzed_modules
"# AM" (info/1)
"# (Mod) app:App"
(application)
"# (Mod) rel:Rel" (release)
no_applications
"# A" (info/1)
no_calls. The sum of the number of resolved and
unresolved calls:
"# (Lin) E" (info/1)
"# (Lin) (E | mod:Mod)" (module)
"# (Lin) (E | app:App)" (application)
"# (Lin) (E | rel:Rel)" (release)
no_functions. The functions
module_info/0,1 are not counted by info.
Assuming that "Extra :=
_:module_info/\"(0|1)\" + _:'$F_EXPR'/_"
has been evaluated, the sum of the number of local and
exported functions are:
"# (F - Extra)" (info/1)
"# (F * mod:Mod - Extra)" (module)
"# (F * app:App - Extra)" (application)
"# (F * rel:Rel - Extra)" (release)
no_function_calls. The sum of the number of
local calls, resolved external calls and unresolved calls:
"# LC + # XC" (info/1)
"# LC | mod:Mod + # XC | mod:Mod" (module)
"# LC | app:App + # XC | app:App" (application)
"# LC | rel:Rel + # XC | mod:Rel" (release)
no_inter_function_calls
"# EE" (info/1)
"# EE | mod:Mod" (module)
"# EE | app:App" (application)
"# EE | rel:Rel" (release)
no_releases
"# R" (info/1)
update(xref() [, Options]) -> {ok, Modules} | Error
Error = {error, module(), Reason}Modules = [module()]Options = [Option] | OptionOption = {verbose, bool()} | {warnings, bool()}Reason = {invalid_options, term()}
| {module_mismatch, module(), ReadModule}
| - see also add_module -
Replaces the module
data of all analyzed modules the BEAM
files of which have been modified since last read by an
add function or update. Application membership
of the modules is retained, and so is the value of the
builtins option. Returns a sorted list
of the names of the replaced modules.
analyze(xref(), Analysis [, Options]) ->
{ok, Answer} | Error
Analysis = undefined_function_calls
| undefined_functions
| locals_not_used | exports_not_used
| {call, FuncSpec}
| {use, FuncSpec}
| {module_call, ModSpec}
| {module_use, ModSpec}
| {application_call, AppSpec}
| {application_use, AppSpec}
| {release_call, RelSpec}
| {release_use, RelSpec}
Answer = [term()]AppSpec = application() | [application()]Error = {error, module(), Reason}FuncSpec = mfa() | [mfa()]ModSpec = module() | [module()]Options = [Option] | OptionOption = {verbose, bool()}RelSpec = release() | [release()]Reason = {invalid_options, term()}
| {parse_error, string_position(), term()}
| {unknown_analysis, term()}
| {unknown_constant, string()}
| {unknown_variable, variable()}
Evaluates a predefined
analysis. Returns a sorted list
without duplicates of call() or constant(),
depending on the chosen analysis.
The predefined analyses, which operate on all analyzed modules, are:
undefined_function_calls
undefined_function
modules mode.
locals_not_used
exports_not_used
{call, FuncSpec}
{use, FuncSpec}
{module_call, ModSpec}
{module_use, ModSpec}
{application_call, AppSpec}
{application_use, AppSpec}
{release_call, RelSpec}
{release_use, RelSpec}
variables(xref() [, Options]) -> {ok, [VariableInfo]}
Options = [Option] | OptionOption = predefined | user | {verbose, bool()}Reason = {invalid_options, term()}VariableInfo = {predefined, [variable()]} | {user, [variable()]}Returns a sorted lists of the names of the variables of an xref server. The default is to return the user variables only.
forget(xref()) -> ok
forget(xref(), Variables) -> ok | Error
Error = {error, module(), Reason}Reason = {not_user_variable, term()}Variables = [variable()] | variable()forget/1 and forget/2 remove all or some of
the user
variables of an xref server.
q(xref(), Query [, Options]) -> {ok, Answer} | Error
Answer = false | [constant()] | [Call] | [Component] | integer()
| [DefineAt] | [CallAt] | [AllLines]Call = call() | ComponentCallComponentCall = {Component, Component}Component = [constant()]DefineAt = {mfa(), LineNumber}CallAt = {funcall(), LineNumbers}AllLines = {{DefineAt, DefineAt}, LineNumbers}Error = {error, module(), Reason}LineNumbers = [LineNumber]LineNumber = integer()Options = [Option] | OptionOption = {verbose, bool()}Query = string() | atom()Reason = {invalid_options, term()}
| {parse_error, string_position(), term()}
| {type_error, string()}
| {type_mismatch, string(), string()}
| {unknown_analysis, term()}
| {unknown_constant, string()}
| {unknown_variable, variable()}
| {variable_reassigned, string()}
Evaluates a query in the context of an xref server, and returns the value of the last statement. The syntax of the value depends on the expression:
call().
constant().
Component.
ComponentCall.
constant(). The list contains the From vertex of each
call and the To vertex of the last call.
of operator returns false if no chain
of calls between the given constants can be found.
closure operator (the
digraph representation) is represented by the atom
'closure()'.
DefineAt.
CallAt.
AllLines.
For both CallAt and AllLines it holds that for
no list element is LineNumbers an empty list; such
elements have been removed. The constants of component
and the integers of LineNumbers are sorted and without
duplicates.
Stops an xref server.
format_error(Error) -> character_list()
Error = {error, module(), term()}Given the error returned by any function of this module,
the function format_error returns a descriptive string
of the error in English. For file errors, the function
format_error/1 in the file module is called.
beam_lib(3), digraph(3), digraph_utils(3), exref(3), regexp(3), TOOLS User's Guide