From 84adefa331c4159d432d22840663c38f155cd4c1 Mon Sep 17 00:00:00 2001 From: Erlang/OTP Date: Fri, 20 Nov 2009 14:54:40 +0000 Subject: The R13B03 release. --- lib/stdlib/doc/src/erl_lint.xml | 159 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 159 insertions(+) create mode 100644 lib/stdlib/doc/src/erl_lint.xml (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 new file mode 100644 index 0000000000..e339f484cc --- /dev/null +++ b/lib/stdlib/doc/src/erl_lint.xml @@ -0,0 +1,159 @@ + + + + +
+ + 19962009 + Ericsson AB. All Rights Reserved. + + + The contents of this file are subject to the Erlang Public License, + Version 1.1, (the "License"); you may not use this file except in + compliance with the License. You should have received a copy of the + Erlang Public License along with this software. If not, it can be + retrieved online at http://www.erlang.org/. + + Software distributed under the License is distributed on an "AS IS" + basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See + the License for the specific language governing rights and limitations + under the License. + + + + erl_lint + Robert Virding + Bjarne Dacker + 1 + Bjarne Däcker + + 97-01-27 + B + erl_lint.sgml +
+ erl_lint + 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.

+

The errors detected include:

+ + redefined and undefined functions + unbound and unsafe variables + illegal record usage. + +

Warnings include:

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

Some of the warnings are optional, and can be turned on by + giving 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 + functions separately unless you have written your own Erlang + compiler.

+ + + + module(AbsForms) -> {ok,Warnings} | {error,Errors,Warnings} + module(AbsForms, FileName) -> {ok,Warnings} | {error,Errors,Warnings} + module(AbsForms, FileName, CompileOptions) -> {ok,Warnings} | {error,Errors,Warnings} + Check a module for errors + + AbsForms = [term()] + FileName = FileName2 = atom() | string() + Warnings = Errors = [{Filename2,[ErrorInfo]}] + ErrorInfo = see separate description below. + CompileOptions = [term()] + + +

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

+ + {ok,Warnings} + +

There were no errors in the module.

+ + {error,Errors,Warnings} + +

There were 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 + 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: +

+ + [{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.

+ + + + is_guard_test(Expr) -> bool() + Test for a guard test + + Expr = term() + + +

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_error(ErrorDescriptor) -> Chars + Format an error descriptor + + ErrorDescriptor = errordesc() + Chars = [char() | Chars] + + +

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).

+ + + + +
+ Error Information +

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

+ + {ErrorLine, Module, ErrorDescriptor} +

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

+ +apply(Module, format_error, ErrorDescriptor) +
+ +
+ See Also +

erl_parse(3), + epp(3)

+
+ + -- cgit v1.2.3