| Age | Commit message (Collapse) | Author |
|---|
|
Libraries or applications that support more than one major
release of OTP may need to use conditional compilation of
Erlang source code. Here are few examples where it would be
necessary or desirable:
* To support a new data type or language feature only available
in the latest major release (real-world examples: maps and the
stacktrace syntax).
* To avoid warnings for deprecated functions.
* To avoid dialyzer warnings.
Previously, to do conditional compilation, one would have to
use a parse transform or some external tool such as 'autoconf'.
To simplify conditional compilation, introduce the -if and -elif
preprocessor directives, to allow code like this to be written:
-if(?OTP_RELEASE =:= 21).
%% Code that will only work in OTP 21.
-else.
%% Fallback code.
-endif.
What kind of expressions should be allowed after an -if?
We certainly don't want to allow anything with a side effect,
such as a '!' or a 'receive'. We also don't want it to be
possible to call erlang:system_info/1, as that could make the
code depedent on features of the run-time system that could
change very easily (such as the number of schedulers).
Requiring the expression to be a guard expression makes most
sense. It is to explain in the documentation and easy for users
to understand. For simplicity of implementation, only a single
guard expression will be supported; that is, the ',' and ';' syntax
for guards is not supported.
To allow some useful conditions to be written, there is a special
built-in function:
defined(Symbol) tests whether the preprocessor symbol is defined,
just like -ifdef. The reason for having this defined/1 is that
the defined test can be combined with other tests, for example:
'defined(SOME_NAME) andalso ?OTP_RELEASE > 21'.
|
|
Add a new pre-defined macro called OTP_RELEASE that will expand
to an integer being the OTP version. Thus, in OTP 19 the value will
be the integer 19.
The OTP_RELEASE macro is particularly useful in order to have
different source code depending on new language features or new
features in the type specification syntax. Those features are only
introduced in major versions of OTP.
To be truly useful, the -if preprocessor directive need to be
implemented. That is the purpose of the next commit.
Code that will need to work in both OTP 18 and OTP 19 can be
structured in the following way:
-ifdef(OTP_RELEASE).
%% Code that only works in OTP 19 and later.
-else.
%% Code that will work in OTP 18.
-endif.
|
|
* maint:
stdlib: Correct a minor epp bug
|
|
The bug was introduced in 87a0af4 (R18).
|
|
|
|
|
|
|
|
|
|
|
|
If one of several alternatives configurations are required for
an Erlang module to compile, but none are available, it would
be useful to give a nice error message. For example:
-ifdef(CONFIG_A).
%% Some code if A is true.
-else.
-ifdef(CONFIG_B).
%% Some code if B is true.
-else.
-error("Neither CONFIG_A nor CONFIG_B are available").
-endif.
-endif.
If neither CONFIG_A nor CONFIG_B are defined, the error message
will be:
module.erl:10: -error("Neither CONFIG_A nor CONFIG_B are available").
That is basically the same behavior as for the #error directive in
GCC.
For symmetry with the -error directive, add the -warning
directive to generate a compiler warning. For example:
-ifdef(HAVE_COOL_FEATURE).
%% Code if we have Cool Feature.
-else.
%% Inefficient fallback code.
-warning("Using inefficient fallback").
-endif.
If HAVE_COOL_FEATURE is not defined, the warning message will
be:
module.erl:8: Warning: -warning("Using inefficient fallback").
That is basically the same behavior as for the #warning directive
in GCC.
Conflicts:
lib/stdlib/src/epp.erl
lib/stdlib/test/epp_SUITE.erl
|
|
scan_include_lib/4 uses a helper function find_lib_dir/1, which has a
strange interface. It takes a string and returns a tuple. The caller
must match the tuple and call fname_join/1 to obtain the desired
result. I assume that the strange interface was not noticed because
the function is only used in one place.
Replace the find_lib_dir/1 with a new expand_lib_dir/1 function which
does the entire job in one go. The new function is much easier to
reuse in other places, which we might want to do in a future commit.
|
|
|
|
For a long time, users have asked for one or more macros that would
return the name and arity of the current function.
We could define a single ?FUNCTION macro that would return
a {Name,Arity} tuple. However, to access just the name or
just the arity for the function, element/2 must be used.
That would limit its usefulness, because element/2 is not
allowed in all contexts.
Therefore, it seems that we will need two macros.
?FUNCTION_NAME that expands to the name of the current function
and ?FUNCTION_ARITY that expands to arity of the current
function.
Converting the function name to a string can be done like this:
f() ->
atom_to_list(?FUNCTION_NAME) ++ "/" ++
integer_to_list(?FUNCTION_ARITY).
f/0 will return "f/0". The BEAM compiler will evaluate the
entire expression at compile-time, so there will not be
any run-time penalty for the function calls.
The implementation is non-trivial because the preprocessor is
run before the parser.
One way to implement the macros would be to replace them with some
placeholder and then let the parser or possibly a later pass replace
the placeholder with correct value. That could potentially slow
down the compiler and cause incompatibilities for parse transforms.
Another way is to let the preprocessor do the whole job. That means
that the preprocessor will have to scan the function head to find
out the name and arity. The scanning of the function head can be
delayed until the first occurrence of a ?FUNCTION_NAME or
?FUNCTION_ARITY.
I have chosen the second way because it seems less likely to cause
weird compatibility problems.
|
|
As a preparation for implementing a ?FUNCTION macro, pass the
entire state record to expand_macros/2 and its helpers. That will
allow us to have more information available when expanding
?FUNCTION.
|
|
Problem: The types of record fields have since R12B been put in a
separate form by epp:parse_file(), leaving the record declaration form
untyped. The separate form, however, does not follow the syntax of
type declarations, and parse transforms inspecting -type() attributes
need to know about the special syntax. Since the compiler stores the
return value of epp:parse_file() as debug information in the abstract
code chunk ("Abst" or 'abstract_code'), tools too need to know about
the special syntax, if they inspect -type() attributes in abstract
code.
Solution: As of this commit no separate form is created by
epp:parse_file(), but the type information kept in the record fields.
This means that all parse transforms and all tools inspecting
-record() declarations need to recognize {typed_record_field, Field,
Type}.
We recommend that all parse transforms and tools be updated as to
recognize typed record fields.
Discussion: As of OTP 19.0, the abstract form of type declarations and
function specifications is documented. An (unsatisfactory) alternative
to the above solution is to document two formats of the abstract form
of typed record fields: one if returned by epp:parse_file(); and one
if returned by, for example, epp:parse_erl_form(). Yet another (bad)
alternative is to not document the format returned by epp:erl_parse(),
but instead document the idempotent function
epp:restore_typed_record_fields/1, and urge authors of parse transform
and tools to always call this function.
|
|
There is no need to flatten filenames using file_name/1 every
time the current filename changes. Any filename obtained from
a source file will be already flattened. Only the original
source filename may need flattening.
|
|
Use maps instead of 'dict'. Remove the {atom,MacroName} wrappers
that were used for historical reasons.
|
|
The Type argument is always 'atom', so there is no need for the
argument.
|
|
|
|
Refactor scan_define() in order to share more between macros
without any arguments and macros with arguments.
|
|
Packages were removed in 34d865a7dfdb33 (R16), but the 'epp'
module was forgotten.
|
|
Record field types have been modified due to commit 8ce35b2:
"Take out automatic insertion of 'undefined' from typed record fields".
|
|
|
|
|
|
The fallback to latin-1 encoding would not work if the invalid
UTF-8 characters occurred in a skipped branch in an -ifdef/-ifndef.
|
|
|
|
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.
|
|
The types array(), dict(), digraph(), gb_set(), gb_tree(), queue(),
set(), and tid() have been deprecated. They will be removed in OTP 18.0.
Instead the types array:array(), dict:dict(), digraph:graph(),
gb_set:set(), gb_tree:tree(), queue:queue(), sets:set(), and ets:tid()
can be used. (Note: it has always been necessary to use ets:tid().)
It is allowed in OTP 17.0 to locally re-define the types array(), dict(),
and so on.
New types array:array/1, dict:dict/2, gb_sets:set/1, gb_trees:tree/2,
queue:queue/1, and sets:set/1 have been added.
|
|
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.
|
|
This adds optional names to fun expressions. A named fun expression
is parsed as a tuple `{named_fun,Loc,Name,Clauses}` in erl_parse.
If a fun expression has a name, it must be present and be the same in
every of its clauses. The function name shadows the environment of the
expression shadowing the environment and it is shadowed by the
environment of the clauses' arguments. An unused function name triggers
a warning unless it is prefixed by _, just as every variable.
Variable _ is allowed as a function name.
It is not an error to put a named function in a record field default
value.
When transforming to Core Erlang, the named fun Fun is changed into
the following expression:
letrec 'Fun'/Arity =
fun (Args) ->
let <Fun> = 'Fun'/Arity
in Case
in 'Fun'/Arity
where Args is the list of arguments of 'Fun'/Arity and Case the
Core Erlang expression corresponding to the clauses of Fun.
This transformation allows us to entirely skip any k_var to k_local
transformation in the fun's clauses bodies.
|
|
|
|
Conflicts:
bootstrap/lib/stdlib/ebin/epp.beam
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
The code related to the introduction of unicode_string() and
unicode_char() has been removed. The types char() and string() have
been extended to include Unicode characters.
In fact char() was changed some time ago; this commit is about
cleaning up the documentation and introduce better names for some
functions.
|
|
|
|
Expect modifications, additions and corrections.
There is a kludge in file_io_server and
erl_scan:continuation_location() that's not so pleasing.
|
|
|
|
Column numbers was merged without understanding all the whole
story. See mail on erlang-patches for details.
This reverts commit df8e67e203b83f95d1e098fec88ad5d0ad840069, reversing
changes made to 0c9d90f314f364e5b1301ec89d762baabc57c7aa.
|
|
|
|
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().
|
|
In the location information tables in the run-time system, source
filenames that are the same as the module name plus ".erl" extension
are not stored explicitly, thus saving memory.
To take advantage of that optimization, avoid complicating the names of
files in the current working directory; specifically, make sure that
"./" is not prepended to the name.
|
|
|
|
|
|
|
|
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.
|
