| Age | Commit message (Collapse) | Author |
|---|
|
Note that this does *not* affect -include()'d files or the -file()
directive.
|
|
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.
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
While we are it, also re-ident the files.
|
|
We want to re-ident the source files after having taken out
all ?line macros. When re-indenting using Emacs, it's important
that comments that should be at the beginning of a line (or
follow the indentation of statements around it) must start with
"%%".
|
|
|
|
There is no practial difference.
|
|
|
|
Either rely on the default 30 minutes timetrap, or set the timeout
using the supported methods in common_test.
|
|
* bjorn/stdlib/function-macro/OTP-13059:
Implement ?FUNCTION_NAME and ?FUNCTION_ARITY macros
epp: Refactor expand_macros()
|
|
* bjorn/remove-test_server/OTP-12705:
Remove test_server as a standalone application
Erlang mode for Emacs: Include ct.hrl instead test_server.hrl
Remove out-commented references to the test_server applications
Makefiles: Remove test_server from include path and code path
Eliminate use of test_server.hrl and test_server_line.hrl
|
|
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.
|
|
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.
|
|
As a first step to removing the test_server application as
as its own separate application, change the inclusion of
test_server.hrl to an inclusion of ct.hrl and remove the
inclusion of test_server_line.hrl.
|
|
Refactor scan_define() in order to share more between macros
without any arguments and macros with arguments.
|
|
|
|
30a4adb7 added smoke and cover test of format_error/1, but did not
catch calls that went through check/2.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
