From 68d53c01b0b8e9a007a6a30158c19e34b2d2a34e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bj=C3=B6rn=20Gustavsson?= Date: Wed, 18 May 2016 15:53:35 +0200 Subject: Update STDLIB documentation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Language cleaned up by the technical writers xsipewe and tmanevik from Combitech. Proofreading and corrections by Björn Gustavsson and Hans Bolinder. --- lib/stdlib/doc/src/erl_lint.xml | 147 +++++++++++++++++++++------------------- 1 file changed, 77 insertions(+), 70 deletions(-) (limited to 'lib/stdlib/doc/src/erl_lint.xml') diff --git a/lib/stdlib/doc/src/erl_lint.xml b/lib/stdlib/doc/src/erl_lint.xml index 3747b0f3c3..77cb7a9916 100644 --- a/lib/stdlib/doc/src/erl_lint.xml +++ b/lib/stdlib/doc/src/erl_lint.xml @@ -28,39 +28,45 @@ 1 Bjarne Däcker - 97-01-27 + 1997-01-27 B - erl_lint.sgml + erl_lint.xml erl_lint - The Erlang Code Linter + The Erlang code linter.

This module is used to check Erlang code for illegal syntax and - other bugs. It also warns against coding practices which are - not recommended.

+ other bugs. It also warns against coding practices that are + not recommended.

+

The errors detected include:

+ - redefined and undefined functions - unbound and unsafe variables - illegal record usage. + Redefined and undefined functions + Unbound and unsafe variables + Illegal record use -

Warnings include:

+ +

The warnings detected include:

+ - unused functions and imports - unused variables - variables imported into matches - variables exported from - if/case/receive - variables shadowed in lambdas and list - comprehensions. + Unused functions and imports + Unused variables + Variables imported into matches + Variables exported from + if/case/receive + Variables shadowed in funs and list comprehensions +

Some of the warnings are optional, and can be turned on by - giving the appropriate option, described below.

+ specifying the appropriate option, described below.

+

The functions in this module are invoked automatically by the - Erlang compiler and there is no reason to invoke these + Erlang compiler. There is no reason to invoke these functions separately unless you have written your own Erlang compiler.

 + @@ -69,86 +75,87 @@ + + + + Format an error descriptor. + +

Takes an ErrorDescriptor and returns a string + that describes the error or warning. This function is usually + called implicitly when processing an ErrorInfo structure + (see section + Error Information).

+ + + + + + Test for a guard test. + +

Tests if Expr is a legal guard test. + Expr is an Erlang term representing the abstract + form for the expression. + erl_parse:parse_exprs(Tokens) + can be used to generate a list of Expr.

+ + + - Check a module for errors + Check a module for errors. -

This function checks all the forms in a module for errors. - It returns: -

+

Checks all the forms in a module for errors. It returns:

{ok,Warnings} -

There were no errors in the module.

+

There are no errors in the module.

 {error,Errors,Warnings} -

There were errors in the module.

+

There are errors in the module.

 -

Since this module is of interest only to the maintainers of - the compiler, and to avoid having the same description in - two places to avoid the usual maintenance nightmare, the +

As this module is of interest only to the maintainers of the + compiler, and to avoid the same description in two places, the elements of Options that control the warnings are - only described in compile(3). -

-

The AbsForms of a module which comes from a file - that is read through epp, the Erlang pre-processor, - can come from many files. This means that any references to - errors must include the file name (see epp(3), or parser erl_parse(3)). - The warnings and errors returned have the following format: -

+ only described in the + + compile(3) module.

+

AbsForms of a module, which comes from a file + that is read through epp, the Erlang preprocessor, can come + from many files. This means that any references to errors must + include the filename, see the + epp(3) module or parser (see the + erl_parse(3) module). + The returned errors and warnings have the following format:

- [{FileName2,[ErrorInfo]}] -

The errors and warnings are listed in the order in which - they are encountered in the forms. This means that the - errors from one file may be split into different entries in - the list of errors.

- - - - - Test for a guard test - -

This function tests if Expr is a legal guard test. - Expr is an Erlang term representing the abstract form - for the expression. erl_parse:parse_exprs(Tokens) can - be used to generate a list of Expr.

- - - - - Format an error descriptor - -

Takes an ErrorDescriptor and returns a string which - describes the error or warning. This function is usually - called implicitly when processing an ErrorInfo - structure (see below).

+[{FileName2,[ErrorInfo]}] +

The errors and warnings are listed in the order in which they are + encountered in the forms. The errors from one file can therefore be + split into different entries in the list of errors.
+ Error Information -

The ErrorInfo mentioned above is the standard - ErrorInfo structure which is returned from all IO - modules. It has the following format: -

+

ErrorInfo is the standard ErrorInfo structure that is + returned from all I/O modules. The format is as follows:

- {ErrorLine, Module, ErrorDescriptor} -

A string which describes the error is obtained with the following call: -

+{ErrorLine, Module, ErrorDescriptor} +

A string describing the error is obtained with the following call:

- Module:format_error(ErrorDescriptor) +Module:format_error(ErrorDescriptor)
See Also -

erl_parse(3), - epp(3)

+

epp(3), + erl_parse(3)

-- cgit v1.2.3