| Age | Commit message (Collapse) | Author |
|---|
|
In the next commit, we will need a way to tell epp which the
default encoding should be for files that have no encoding comment.
We could add new open() and parse_file() functions with one
extra argument for the encoding, but there are already too many
variants.
To avoid having to add an additional argument to epp:open() and
epp:parse_file() each time new options are needed, introduce
epp:open/1 and epp:parse_file/2 that takes a property list with
options. Also support the new 'default_encoding' option for specifying
the default encoding for source files.
Thanks to Richard Carlsson for the idea and the implementation
of the new functionality in epp.erl.
|
|
epp could loop when encountering a circular macro definition in an
included file.
Thanks to Maruthavanan Subbarayan for reporting the bug, and to
Richard Carlsson for providing a bug fix.
|
|
When entering a new file, epp doesn't properly set #epp.name2 like it
does on initialisation, generating a malformed file attribute when it
leaves the file.
|
|
Also let the Erlang shell use the new function io:printable_range().
|
|
|
|
Expect modifications, additions and corrections.
There is a kludge in file_io_server and
erl_scan:continuation_location() that's not so pleasing.
|
|
This is because this test case itself starts and stops cover.
|
|
|
|
The expected behaviour of a C-style preprocessor (such as Erlang's epp) is
to allow a header file to include another header file in the same directory
even though that directory is not explicitly in the include path, and even
if the actual include path might reference another directory containing a
file with the same name. For example, if src/foo.erl explicitly includes
"../include/foo.hrl", then foo.hrl should be able to include "bar.hrl" in
that same directory even though "../include" might not be in the search
path, and even if another file named bar.hrl could be found using the search
path it should not override the one in the same directory as foo.hrl.
In Erlang, the most common situation is that a user of an installed
application includes a main public header file using include_lib
("appname/include/foo.hrl") and that file includes a secondary header file
"bar.hrl". However, if it does this using include_lib, it causes a
bootstrapping problem - in the build environment for the application itself,
the application is not necessarily found by name. On the other hand, if
foo.hrl uses a plain include, then bar.hrl might be found when the
application is built (if explicit paths are set in the makefils) but not
later on when a user includes the main header file of the installed
application via include_lib.
By making -include always look in the directory of the current file before
it uses the search path, this problem is remedied, and include directives
behave in a more intuitive way.
This completes a partial fix in R11 that only worked for include_lib().
|
|
Running Dialyzer on the test suites revealed a few type errors.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Cover did not collect coverage data for files such as Yecc parses
containing include directives. The bug has been fixed by modifying
epp, the Erlang Code Preprocessor.
|
|
The Erlang code preprocessor (epp) did not correctly handle premature
end-of-input when defining macros. This bug, introduced in STDLIB 1.16, has
been fixed.
|
|
When defining macros the closing right parenthesis before the dot is now
mandatory.
|
|
The empty record (no fields) is now considered typed.
It is more consistent than before; the base case is
the logical one.
A record is typed iff all its fields are typed.
A record is tagged 'typed' iff it is typed.
|
|
The Erlang code preprocessor (epp) sent extra messages on the form
{eof,Location} to the client when parsing the file attribute. This bug,
introduced in R11B, has been fixed.
|
|
|
|
Now, when we have only the constant definition of a macro (without
arguments), we always use it. In all other cases, we try to find the
exact matching definition. We throw an error if we don't find it.
|
|
This feature simplifies the definition of macros by avoiding to have a
different name for each version (with different arities) of the same
macros. New rules:
- can have multiple definitions of the same macro with different arities
- cannot overload macro with the same arity
- the overloading of predefined macros (?MODULE, ?LINE, ...) is forbidden
- the directive '-undef' removes all definitions of a macro
|
|
|
