epp_dodger

MODULE

epp_dodger

MODULE SUMMARY

epp_dodger - bypasses the Erlang preprocessor.

DESCRIPTION

epp_dodger - bypasses the Erlang preprocessor.

This module tokenises and parses most Erlang source code without
expanding preprocessor directives and macro applications, as long as
these are syntactically "well-behaved". Because the normal parse
trees of the erl_parse module cannot represent these things
(normally, they are expanded by the Erlang preprocessor epp(3) before the parser sees them), an extended syntax tree
is created, using the erl_syntax module.

Reads and parses program text from an I/O stream. Characters are
read from IODevice until end-of-file; apart from this, the
behaviour is the same as for parse_file/2. StartLine is the
initial line number, which should be a positive integer.

Reads and parses a file. If successful, {ok, Forms}
is returned, where Forms is a list of abstract syntax
trees representing the "program forms" of the file (cf.
erl_syntax:is_form/1). Otherwise, {error, errorinfo()} is
returned, typically if the file could not be opened. Note that
parse errors show up as error markers in the returned list of
forms; they do not cause this function to fail or return
{error, errorinfo()}.

Options:

{no_fail, boolean()}

If true, this makes epp_dodger replace any program forms
that could not be parsed with nodes of type text (see erl_syntax:text/1), representing the raw token sequence of the
form, instead of reporting a parse error. The default value is
false.

{clever, boolean()}

If set to true, this makes epp_dodger try to repair the
source code as it seems fit, in certain cases where parsing would
otherwise fail. Currently, it inserts ++-operators between string
literals and macros where it looks like concatenation was intended.
The default value is false.

Reads and parses a single program form from an I/O stream.
Characters are read from IODevice until an end-of-form
marker is found (a period character followed by whitespace), or until
end-of-file; apart from this, the behaviour is similar to that of
parse/3, except that the return values also contain the
final line number given that StartLine is the initial
line number, and that {eof, LineNo} may be returned.

Similar to parse_file/2, but does a more quick-and-dirty
processing of the code. Macro definitions and other preprocessor
directives are discarded, and all macro calls are replaced with
atoms. This is useful when only the main structure of the code is of
interest, and not the details. Furthermore, the quick-parse method
can usually handle more strange cases than the normal, more exact
parsing.

Options: see parse_file/2. Note however that for
quick_parse_file/2, the option no_fail is true by default.