| Age | Commit message (Collapse) | Author |
|---|
|
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
"%%".
|
|
|
|
|
|
|
|
|
|
|
|
The return values for lists:prefix/2 and lists:member/2 were
ignored.
|
|
Note that the sleeping time in ct:sleep/1 will be scaled if
the test is run with (for example) cover. When it is important
that the sleep time is not adjusted, use timer:sleep/1.
|
|
|
|
There is no practial difference.
|
|
|
|
Either rely on the default 30 minutes timetrap, or set the timeout
using the supported methods in common_test.
|
|
Conflicts:
lib/common_test/test/Makefile
|
|
* siri/test-ct_release_test/OTP-13390:
Remove upgrade tests from stdlib_SUITE
Add test of ct_release_test
|
|
The test cases minor_upgrade and major_upgrade used
ct_release_test. The point of the tests in stdlib was mainly to test
ct_release_test. ct_release_test produces a 'from-release' based on an
old version of the application under test (in this case stdlib) and
new versions of all other applications. But since it is not always a
good idea to load an old version of stdlib into a new emulator
(e.g. in the OTP-19.0 emulator), these tests are removed.
Instead new tests are added for ct_release_test in common_test.
|
|
* maint:
io_SUITE: Don't fail on fast computers with rough timers
Fix code_SUITE after test_server change
Set default value for crash_dump_dir
|
|
* bjorn/cuddle-with-tests:
io_SUITE: Don't fail on fast computers with rough timers
|
|
|
|
* henrik/doc-fixes:
Fix typo in INSTALL.md
Update README.md
Fix typo in 'app' documentation
s/is/are
|
|
|
|
* sverk/bad_printable_range:
stdlib: Fix io_SUITE:bad_printable_range for windows
|
|
Since Windows 8 we are not allowed (in non elevated mode) to
write to hklm.
|
|
avoid os:cmd as it treats stderr different on windows.
|
|
On a computer which is fast, but with timers with low resolution,
the measured time for an empty queue could be zero, which could
cause the test case to fail.
Add a calibration function to scale up the amount the amount of
work so that the measured time will not be lower than 50 ms.
|
|
* bjorn/compiler/binary-comprehensions/OTP-13289:
Generalize bit string comprehensions
|
|
|
|
|
|
|
|
The expression in a bit string comprehension is limited to a
literal bit string expression. That is, the following code
is legal:
<< <<X>> || X <- List >>
but not this code:
<< foo(X) || X <- List >>
The limitation is annoying. For one thing, tools that transform
the abstract format must be careful not to produce code such as:
<< begin
%% Some instrumentation code.
<<X>>
end || X <- List >>
One reason for the limitation could be that we'll get
reduce/reduce conflicts if we try to allow an arbitrary
expression in a bit string comprehension:
binary_comprehension -> '<<' expr '||' lc_exprs '>>' :
{bc,?anno('$1'),'$2','$4'}.
Unfortunately, there does not seem to be an easy way to work
around that problem. The best we can do is to allow 'expr_max'
expressions (as in the binary syntax):
binary_comprehension -> '<<' expr_max '||' lc_exprs '>>' :
{bc,?anno('$1'),'$2','$4'}.
That will work, but functions calls must be enclosed in
parentheses:
<< (foo(X)) || X <- List >>
|
|
|
|
|
|
* siri/remove-overload/OTP-13184:
Remove module 'overload' from SASL
|
|
|
|
|
|
* benwilson512/better-maps-with:
Improved maps:with/2 and maps:without/2 algorithm
OTP-13376
|
|
|
|
The reason is that the module is not used, and that we se no obvious
use case for it.
|
|
Forms with record field types created before OTP 19.0 are replaced by
well-formed record forms holding the type information.
Tools reading the 'abstract_code' chunk can rely on the returned forms
being well-formed, that is, there are no badly formed 'type' attribute
forms.
|
|
* 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.
|
|
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.
|
