erl_lint(3)

erl_lint(3) — the Erlang code linter 💅✨

okay bestie, welcome to the erl_lint page, straight out of the Erlang Module Definition section of the manual. she's the vibe-checker for your Erlang code and she does not miss. 🎀

✨ NAME ✨

erl_lint — the Erlang code linter. that's it, that's the whole name, periodt. 👑

---

🌸 DESCRIPTION 🌸

so basically this module exists to snoop through your Erlang code and catch illegal syntax plus other bugs. she also side-eyes coding practices that are Not Recommended, like a friend who gently says "girl…" 😭

the errors she detects include:

• Redefined and undefined functions
• Unbound and unsafe variables
• Illegal record use

the warnings she detects include:

• 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 these warnings are optional, and you turn them on by specifying the appropriate option — described below, iykyk. 🌈

the functions in this module get invoked automatically by the Erlang compiler. so unless you've written your own Erlang compiler (main character energy ✨), there is literally no reason to invoke these functions separately. no cap.

💜 Error Information

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

{ErrorLine, Module, ErrorDescriptor}

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

Module:format_error(ErrorDescriptor)

🫶 See Also

epp, erl_parse

---

🦋 DATA TYPES 🦋

error_description() :: term().

error_info() ::
          {erl_anno:location() | none, module(), error_description()}.

fa() :: {atom(), arity()}.

fun_used_vars() ::
          #{erl_parse:abstract_expr() => {[atom()], fun_used_vars()}}.

---

💖 FUNCTIONS 💖

format_error(ErrorDescriptor) -> io_lib:chars()

when ErrorDescriptor :: error_description().

takes an ErrorDescriptor and hands you back a string that describes the error or warning. this one is usually called implicitly when processing an ErrorInfo structure — see the Error Information section up there. 💅

---

is_guard_test(Expr) -> boolean()

when Expr :: erl_parse:abstract_expr().

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

---

module(AbsForms, FileName, CompileOptions) -> {ok, Warnings} | {error, Errors, Warnings}

when
    AbsForms ::
        [erl_parse:abstract_form() |
         erl_parse:form_info()],
    FileName :: atom() | string(),
    CompileOptions :: [compile:option()],
    Warnings :: [{SourceFile, [ErrorInfo]}],
    Errors :: [{SourceFile, [ErrorInfo]}],
    SourceFile :: file:filename(),
    ErrorInfo :: error_info().

checks all the forms in a module for errors. it returns:

• {ok,Warnings} — there are no errors in the module. slay. 🎉
• {error,Errors,Warnings} — there are errors in the module. 💀

so, because this module is of interest only to the maintainers of the compiler — and to avoid writing the same description in two places — the elements of Options that control the warnings are only described in the compile module. go check her out. 🧚

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

[{SourceFile,[ErrorInfo]}]

the errors and warnings are listed in the order in which they're encountered in the forms. so the errors from one file can absolutely be split into different entries in the list of errors. she contains multitudes. ✨

---

fr fr, that's the whole page. go run your code through her, bestie, she'll tell you the truth. 🫶

anywayyy, this whole thing came to you from Ericsson AB, version stdlib 8.0.4, and it's the erl_lint(3) page — mwah, take care of her, she's iconic. 💖👑