aboutsummaryrefslogtreecommitdiffstats
path: root/lib/debugger/test
AgeCommit message (Collapse)Author
2017-11-17Avoid using the efile driver in test suitesBjörn Gustavsson
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.
2017-03-08debugger: Fix handling of locations and annotationsHans Bolinder
2017-01-25Update test cases for erlang:hash/2 removalBjörn-Egil Dahlberg
2016-09-02Fix overridden BIFsBjörn Gustavsson
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
2016-09-01debugger: Eliminate use of sys_pre_expandBjörn Gustavsson
2016-08-04Move expansion of strings in binaries to v3_coreJosé Valim
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
2016-04-18Remove ?line macrosBjörn Gustavsson
While we are it, also re-ident the files.
2016-04-18Replace "%" with "%%" at the beginning of a lineBjörn Gustavsson
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 "%%".
2016-04-18Eliminate doc and suite clausesBjörn Gustavsson
2016-04-18Eliminate use of the ?t macroBjörn Gustavsson
2016-04-18Eliminate use of test_server:format()Björn Gustavsson
2016-04-18Eliminate use of test_server:fail/{0,1}Björn Gustavsson
2016-04-18Use proplists:get_value/2 instead of ?config()Björn Gustavsson
2016-04-18Modernize use of timetrapsBjörn Gustavsson
Either rely on the default 30 minutes timetrap, or set the timeout using the supported methods in common_test.
2016-04-18int_SUITE: Fix interpretable/1 in a non-installed systemBjörn Gustavsson
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.
2016-04-18int_SUITE: Fix interpretable/1 on cross-compiled platformsBjörn Gustavsson
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.
2016-03-15update copyright-yearHenrik Nord
2016-02-26Merge branch 'josevalim/debugger-path/OTP-13375'Björn Gustavsson
* josevalim/debugger-path/OTP-13375: Use compile source info in debugger
2016-02-23Use compile source info in debuggerJosé Valim
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).
2016-02-17Makefiles: Remove test_server from include path and code pathBjörn Gustavsson
Since no test suites includede test_server.hrl, there is no need to have test_server in the include path or code path.
2016-02-17Eliminate use of test_server.hrl and test_server_line.hrlBjörn Gustavsson
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.
2015-12-11debugger tests: Replace 'random' with 'rand'Björn Gustavsson
2015-06-22fix errors caused by changed line numbersBruce Yinhe
2015-06-18Change license text to APLv2Bruce Yinhe
2015-05-25debugger: Relax test map_SUITE:t_guard_receive_large/1Björn-Egil Dahlberg
Would timeout on slow machines and was unnecessary large.
2015-04-30debugger test suite: Scale down t_frequency_table/1Björn Gustavsson
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.
2015-04-15Raise more descriptive error messages for failed map operationsBjörn Gustavsson
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.
2015-03-30debugger: Strengthen Maps testsBjörn-Egil Dahlberg
2015-03-27debugger: Strengthen Maps testsBjörn-Egil Dahlberg
2015-03-12erts: Make is_members in map_SUITE's more stringentSverker Eriksson
2015-03-12debugger: Fix maps testcase unordered enc/decBjörn-Egil Dahlberg
2015-03-12debugger: Update map tests for unordered mapsBjörn-Egil Dahlberg
2014-08-26debugger: Update Map testsBjörn-Egil Dahlberg
2014-05-03Fix evaluation of map updates in the debugger and erl_evalAnthony Ramine
Reported-by: José Valim
2014-03-18Merge branch 'nox/maps-eval-empty-update'Björn-Egil Dahlberg
* 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
2014-03-15Fix evaluation of empty map updates in the debuggerAnthony Ramine
2014-03-14erts: Change external format for mapsSverker Eriksson
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.
2014-02-24Merge branch 'schlagert/fix_basic_appups'Siri Hansen
* 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
2014-02-24Add test suites performing app and appup file checksTobias Schlager
Add the mentioned test suites for *all* library and touched non-library applications.
2014-02-20Speed up bs_construct_SUITE:dynamic/1Björn Gustavsson
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.
2014-02-10Merge branch 'nox/debugger/erl_eval_SUITE/OTP-11676'Björn Gustavsson
* nox/debugger/erl_eval_SUITE/OTP-11676: Truly test debugger in erl_eval_SUITE copy
2014-02-10Truly test debugger in erl_eval_SUITE copyAnthony Ramine
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.
2014-02-06debugger: Fix release_testsBjörn-Egil Dahlberg
2014-02-04Support maps in the debuggerAnthony Ramine
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.
2014-01-09Merge branch 'nox/fix-dbg_ieval-exporting-rules/OTP-11553'Björn Gustavsson
* 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
2013-12-15Fix evaluation of andalso and orelse in the debuggerAnthony Ramine
Their exporting rules were not respected.
2013-12-12Test named funsAnthony Ramine
2013-09-12Remove ^L characters hidden randomly in the code. Not those used in text ↵Pierre Fenoll
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.
2013-06-14Fix binary construction on floating point middle-endian machinesJohannes Weißl
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).
2013-06-14Fix binary matching on floating point middle-endian machinesJohannes Weißl
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.