| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
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.
|
|
The application/module 'gs' is not available on all platforms.
|
|
|
|
Conflicts:
lib/diameter/autoconf/vxworks/sed.general
xcomp/README.md
|
|
|
|
Tuple funs were deprecated in R15B (in commit a4029940e309518f5500).
|
|
* lukas/otp/install_with_whitespace/OTP-10107:
Update to work with space in include path
Update to work with whitespace in exec path
|
|
OTP-10106
OTP-10107
|
|
|
|
|
|
Reported by Ricardo Catalinas Jiménez
|
|
Some bit syntax test cases take much longer time to complete when
libraries are in native code, probably because of context switches
between the eval_bits module and the debugger modules.
|
|
|
|
Currently, the external fun syntax "fun M:F/A" only supports
literals. That is, "fun lists:reverse/1" is allowed but not
"fun M:F/A".
In many real-life situations, some or all of M, F, A are
not known until run-time, and one is forced to either use
the undocumented erlang:make_fun/3 BIF or to use a
"tuple fun" (which is deprecated).
EEP-23 suggests that the parser (erl_parse) should immediately
transform "fun M:F/A" to "erlang:make_fun(M, F, A)". We have
not followed that approach in this implementation, because we
want the abstract code to mirror the source code as closely
as possible, and we also consider erlang:make_fun/3 to
be an implementation detail that we might want to remove in
the future.
Instead, we will change the abstract format for "fun M:F/A" (in a way
that is not backwards compatible), and while we are at it, we will
move the translation from "fun M:F/A" to "erlang:make_fun(M, F, A)"
from sys_pre_expand down to the v3_core pass. We will also update
the debugger and xref to use the new format.
We did consider making the abstract format backward compatible if
no variables were used in the fun, but decided against it. Keeping
it backward compatible would mean that there would be different
abstract formats for the no-variable and variable case, and tools
would have to handle both formats, probably forever.
Reference: http://www.erlang.org/eeps/eep-0023.html
|
|
|
|
|
|
This commit is a preparation for introducing location information
(filename/line number) in stacktraces in exceptions. Currently
a stack trace looks like:
[{Mod1,Function1,Arity1},
.
.
.
{ModN,FunctionN,ArityN}]
Add a forth element to each tuple that can be used indication
the filename and line number of the source file:
[{Mod1,Function1,Arity1,Location1},
.
.
.
{ModN,FunctionN,ArityN,LocationN}]
In this commit, the fourth element will just be an empty list,
and we will change all code that look at or manipulate stacktraces.
|
|
The stacktrace in debugger-generated exceptions should be
as similar to stacktraces in BEAM-generated exceptions as
possible.
|
|
'eval_bits' is a common utility module used for evaluting binary
construction and matching. The functions that do matching
(match_bits/{6,7} and bin_gen/6) are supposed to treat the bindings as
an abstract data type, but they assume that the bindings have the same
representation as in the erl_eval module. That may cause binary
matching to fail in the debugger, because the debugger represents the
bindings as an unordered list of two-tuples, while the erl_eval
modules uses an ordered list of two-tuple (an ordset).
One way to fix the problem would be to let the debugger to use ordered
lists to represent the bindings. Unfortunately, that would also change
how the bindings are presented in the user interface. Currently, the
variable have most been recently assigned is shown first, which is
convenient.
Fix the matching problem by mending the leaky abstraction in
eval_bits. The matching functions needs to be passed two additional
operations: one for looking up a variable in the bindings and one for
adding a binding. Those operations could be passed as two more funs
(in addition to the evaluation and match fun already passed), but the
functions already have too many arguments. Therefore, change the
meaning of the match fun, so that the first argument is the operation
to perform ('match', 'binding', or 'add_binding') and second argument
is a tuple with arguments for the operation.
|
|
|
|
A long time ago, test suites were copied from other applications.
Copy the tests again to get more test cases.
|
|
* hw/call-chmod-without-f:
Call chmod without the "-f" flag
Conflicts:
erts/emulator/test/Makefile
lib/asn1/test/Makefile
lib/crypto/test/Makefile
lib/debugger/test/Makefile
lib/docbuilder/test/Makefile
lib/edoc/test/Makefile
lib/erl_interface/test/Makefile
lib/inviso/test/Makefile
lib/parsetools/test/Makefile
lib/percept/test/Makefile
lib/ssl/test/Makefile
lib/syntax_tools/test/Makefile
lib/test_server/test/Makefile
lib/tools/test/Makefile
OTP-9170
|
