| Age | Commit message (Collapse) | Author |
|---|
|
The efile driver will soon be reimplemented as a BIF.
Instead of opening a port based on efile, use hd(erlang:ports()). It
is a reasonable safe assumption that the runtime will continue to use
use at least some ports.
|
|
|
|
|
|
The filters in a list comprehension can be guard expressions or
an ordinary expressions.
If a guard expression is used as a filter, an exception will basically
mean the same as 'false':
t() ->
L = [{some_tag,42},an_atom],
[X || X <- L, element(1, X) =:= some_tag]
%% Returns [{some_tag,42}]
On the other hand, if an ordinary expression is used as a filter, there
will be an exception:
my_element(N, T) -> element(N, T).
t() ->
L = [{some_tag,42},an_atom],
[X || X <- L, my_element(1, X) =:= some_tag]
%% Causes a 'badarg' exception when element(1, an_atom) is evaluated
It has been allowed for several releases to override a BIF with
a local function. Thus, if we define a function called element/2,
it will be called instead of the BIF element/2 within the module.
We must use the "erlang:" prefix to call the BIF.
Therefore, the following code is expected to work the same way as in
our second example above:
-compile({no_auto_import,[element/2]}).
element(N, T) ->
erlang:element(N, T).
t() ->
L = [{some_tag,42},an_atom],
[X || X <- L, element(1, X) =:= some_tag].
%% Causes a 'badarg' exception when element(1, an_atom) is evaluated
But the compiler refuses to compile the code with the following
diagnostic:
call to local/imported function element/2 is illegal in guard
|
|
|
|
This speeds up the compilation of binary literals
with string values in them. For example, compiling
a file with a ~340kB binary would yield the following
times by the compiler:
Compiling "foo"
parse_module : 0.130 s 5327.6 kB
transform_module : 0.000 s 5327.6 kB
lint_module : 0.011 s 5327.8 kB
expand_module : 0.508 s 71881.2 kB
v3_core : 0.463 s 11.5 kB
Notice the increase in memory and processing time
in expand_module and v3_core. This happened because
expand_module would expand the string in binaries
into chars. For example, the binary <<"foo">>, which
is represented as
{bin, 1, [
{bin_element, 1, {string, 1, "foo"}, default, default}
]}
would be converted to
{bin, 1, [
{bin_element, 1, {char, 1, $f}, default, default},
{bin_element, 1, {char, 1, $o}, default, default},
{bin_element, 1, {char, 1, $o}, default, default}
]}
However, v3_core would then traverse all of those
characters and convert it into an actual binary, as it
is a literal value.
This patch addresses this issue by moving the expansion
of string into chars to v3_core and only if a literal
value cannot not be built. This reduces the compilation
time of the file mentioned above to the values below:
Compiling "bar"
parse_module : 0.134 s 5327.6 kB
transform_module : 0.000 s 5327.6 kB
lint_module : 0.005 s 5327.8 kB
expand_module : 0.000 s 5328.7 kB
v3_core : 0.013 s 11.2 kB
|
|
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
"%%".
|
|
|
|
|
|
|
|
|
|
|
|
Either rely on the default 30 minutes timetrap, or set the timeout
using the supported methods in common_test.
|
|
interpretable/1 tests (among other things) that we are not allowed
to interpret modules in certain applications (such as kernel and
stdlib).
int:interpretable/1 as currently implement enforces the restriction
only in an installed system (the applications must have versions,
such as kernel-1.2.3).
We could modify int:interpretable/1 to enforce the restriction,
but it could sometimes be useful to be able to debug (for example)
erl_lint or other library modules that can safely be reloaded
without crashing the run-time system.
Therefore, assume that anyone working in a non-installed system
knows what they are doing and fix the test case so that it stop
failing in a non-installed system.
|
|
c7e82c6b406b teached the debugger to use the 'source' key
in Mod:module_info/1 to help locate the source code
corresponding to a BEAM file. The new test that was added
at the same time will fail if the test suites were
cross-compiled on another computer (i.e., the 'source' key
would not point to the source file on the target computer).
Avoid the problem by letting int_SUITE:init_per_suite/1 compile
the BEAM files. That will ensure that 'source' keys points to
the actual source file.
|
|
|
|
* josevalim/debugger-path/OTP-13375:
Use compile source info in debugger
|
|
Prior to this commit, the debugger relied on a simple heuristic
that traverses directory from the beam file to find a source file.
The heuristic was maintained with this patch but, if it fails,
it fallbacks to the source value in the module compile info.
In order to illustrate how it works, one of the tests that
could not find its source now passes successfully (showing the
source lookup is more robust).
|
|
Since no test suites includede test_server.hrl, there is no need
to have test_server in the include path or code path.
|
|
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.
|
|
|
|
|
|
|
|
Would timeout on slow machines and was unnecessary large.
|
|
t_frequency_table/1 would take about 40 seconds on my computer.
Scale down the number of iterations 100 times to speed it up.
The large number of iterations does not find any more bugs in
the debugger.
|
|
According to EEP-43 for maps, a 'badmap' exception should be
generated when an attempt is made to update non-map term such as:
<<>>#{a=>42}
That was not implemented in the OTP 17.
José Valim suggested that we should take the opportunity to
improve the errors coming from map operations:
http://erlang.org/pipermail/erlang-questions/2015-February/083588.html
This commit implement better errors from map operations similar
to his suggestion.
When a map update operation (Map#{...}) or a BIF that expects a map
is given a non-map term, the exception will be:
{badmap,Term}
This kind of exception is similar to the {badfun,Term} exception
from operations that expect a fun.
When a map operation requires a key that is not present in a map,
the following exception will be raised:
{badkey,Key}
José Valim suggested that the exception should be
{badkey,Key,Map}. We decided not to do that because the map
could potentially be huge and cause problems if the error
propagated through links to other processes.
For BIFs, it could be argued that the exceptions could be simply
'badmap' and 'badkey', because the bad map and bad key can be found in
the argument list for the BIF in the stack backtrace. However, for the
map update operation (Map#{...}), the bad map or bad key will not be
included in the stack backtrace, so that information must be included
in the exception reason itself. For consistency, the BIFs should raise
the same exceptions as update operation.
If more than one key is missing, it is undefined which of
keys that will be reported in the {badkey,Key} exception.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Reported-by: José Valim
|
|
* nox/maps-eval-empty-update:
Fix evaluation of empty map patterns in erl_lint
Fix evaluation of empty map updates in the debugger
Fix evaluation of empty map updates in erl_eval
|
|
|
|
to be: 116,Arity, K1,V1,K2,V2,...,Kn,Vn
instead of: 116,Arity, K1,K2,...,Kn, V1,V2,....,Vn
We think this will be better for future internal map structures
like HAMT. Would be bad if we need to iterate twice over HAMT
in term_to_binary, one for keys and one for values.
|
|
* schlagert/fix_basic_appups:
Dynamically configure typer_SUITE according to environment
Disable hipe_SUITE when environment doesn't support it
Make hipe non-upgradable by setting appup file empty
Fix missing module on hipe app file template
Add test suites performing app and appup file checks
Introduce appup test utility
Fix library application appup files
Fix non-library appup files according to issue #240
OTP-11744
|
|
Add the mentioned test suites for *all* library and touched
non-library applications.
|
|
The original test comes from the emulator test suite for testing
binary syntax in the run-time system.
Running interpreted it can be quite slow, especially when the system
has been compiled with the configure option --enable-native-libs
(probably because of very many context switches between native code
and BEAM code).
Speed up the test by scaling down the size of binaries from 128
bits to 64 bits. That should speed up the test roughly four times.
By running the little and big endian tests in parallel we will
cut that time in half. Thus all in all the test will run roughly
8 times faster.
|
|
* nox/debugger/erl_eval_SUITE/OTP-11676:
Truly test debugger in erl_eval_SUITE copy
|
|
The module was not interpreted.
This surfaced two bugs, related to shadowed variables in binary patterns in
comprehension generators, and guard filters not properly detected. The guard
detection code from dbg_iload is deleted in favor of erl_lint:is_guard_test/1.
The erl_lint module is now safe to use because it can handle all expressions
emitted by sys_pre_expand, the following warning is thus obsolete and has been
removed from code:
%% Cannot use erl_lint here as sys_pre_expand has transformed source.
|
|
|
|
A test is commented-out in map_SUITE:t_update_exact/1, waiting for a fixed
maps:update/3 function with correct integer/float semantics.
|
|
* nox/fix-dbg_ieval-exporting-rules/OTP-11553:
compiler tests: Test exporting rules for andalso/orelse
Fix evaluation of andalso and orelse in the debugger
|
|
Their exporting rules were not respected.
|
|
|
|
files as delimiters.
While working on a tool that processes Erlang code and testing it against this repo,
I found out about those little sneaky 0xff. I thought it may be of help to other
people build such tools to remove non-conforming-to-standard characters.
|
|
This complements 933e701 (OTP-10209). Without this patch the test cases
"in_guard/1" and "coerce_to_float/1" in bs_construct_SUITE fail.
The added lines in bs_construct_SUITE cover all branches that were not
covered before (small and big numbers if BIT_OFFSET(erts_bin_offset) != 0).
|
|
This complements 933e701 (OTP-10209). Without this patch the test case
"bs_match_misc_SUITE:t_float/1" fails.
Simple error example:
1> <<_,_,_,_,_,_,_,_>> = <<1.25/float>>.
<<63,244,0,0,0,0,0,0>>
2> <<1.25/float>> = <<63,244,0,0,0,0,0,0>>.
** exception error: no match of right hand side value <<63,244,0,0,0,0,0,0>>
The additional test case is added because in a former version of this
patch the ERTS_FP_ERROR_THOROUGH check for NaN/infinity was mistakenly
applied on the still word-switched double.
|
