aboutsummaryrefslogtreecommitdiffstats
path: root/lib/compiler/test/test_lib.erl
AgeCommit message (Collapse)Author
2016-03-15update copyright-yearHenrik Nord
2016-02-25Replace use of lists:keysearch/3 with lists:keyfind/3Björn Gustavsson
2016-02-25Replace ?t with test_serverBjörn Gustavsson
The macro ?t is deprecated. Replace its use with 'test_server'.
2016-02-25Eliminate use of test_server:fail/0,1Björn Gustavsson
2016-02-25Eliminate use of ?config() macroBjörn Gustavsson
?config is ugly and not recommended. Use proplists:get_value/2 instead.
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-06-18Change license text to APLv2Bruce Yinhe
2015-04-29test_lib: Simplify uniq/0Björn Gustavsson
Simplify the uniq/0 function by using erlang:unique_integer/1.
2015-02-12test_lib: Include test_server.hrl using -include_libBjörn Gustavsson
This module is the last that uses -include() instead of include_lib(). With that change, a quick smoke test can be done simply like this: PATH=$ERL_TOP/bin:$PATH erlc -W0 *.erl Without the change, you would also need to add -I $ERL_TOP/lib/test_server/include to the command line.
2015-02-03Teach case_opt/3 to avoid unnecessary buildingBjörn Gustavsson
Given this code: f(S) -> F0 = F1 = {S,S}, [F0,F1]. case_opt/3 would "optimize" it like this: f(S) -> F1 = {S,S}, F0 = {S,S}, [F0,F1]. Similarly, this code: g({a,_,_}=T) -> {b, [_,_] = [T,none], x}. would be rewritten to: g({a,Tmp1,Tmp2}=T) -> Tmp3 = {a,Tmp1,Tmp2}, {b, [Tmp3,none], x}. where the tuple is rebuilt instead of using the T variable. Rewrite case_opt/3 to be more careful while optimizing.
2015-01-26Speed up running of compiler test suites in coverage modeBjörn Gustavsson
I have spent too much time lately waiting for 'cover' to finish, so now its time to optimize the running time of the tests suite in coverage mode. Basically, when 'cover' is running, the test suites would not run any tests in parallel. The reason is that using too many parallel processes when running 'cover' would be slower than running them sequentially. But those measurements were made several years ago, and many improvements have been made to improve the parallelism of the run-time system. Experimenting with the test_lib:p_run/2 function, I found that increasing the number of parallel processes would speed up the self_compile tests cases in compilation_SUITE. The difference between using 3 processes or 4 processes was slight, though, so it seems that we should not use more than 4 processes when running 'cover'. We don't want to change test_lib:parallel/0, because there is no way to limit the number of test cases that will be run in parallel by common_test. However, there as test suites (such as andor_SUITE) that don't invoke the compiler at run-time. We can run the cases in such test suites in parallel even if 'cover' is running.
2013-01-25Update copyright yearsBjörn-Egil Dahlberg
2012-10-23compiler: Run testcases in parallelBjörn Gustavsson
Run testcases in parallel will make the test suite run slightly faster. Another reason for this change is that we want more testing of parallel testcase support in common_test.
2012-01-04test_lib:p_run/2: Be careful about how many parallel processes we useBjörn Gustavsson
We probably don't gain anything by using more processes than available schedulers. Also, if 'cover' is being run, using more than one process may make it slower, so we will be very conservative and use only one process in that case.
2011-02-23compiler: Eliminate some warningsBjörn Gustavsson
2010-06-02Add some testcases to compiler to verify that overriding really happensPatrik Nyblom
2010-05-10Move p_run/2 to test_libBjörn Gustavsson
It can be useful for other test suites.
2010-03-26compiler tests: Test the 'inline' option betterBjörn Gustavsson
Clone some test suites and compile them with the 'inline' option to test inlining more thorughly.
2010-03-25Merge branch 'bg/compiler-remove-r11-support' into devErlang/OTP
* bg/compiler-remove-r11-support: compiler: Don't support the no_binaries option erts: Don't support the put_string/3 instruction compiler: Don't support the no_constant_pool option compiler: Don't support the r11 option test_server: Don't support communication with R11 nodes binary_SUITE: Don't test bit-level binary roundtrips with R11 nodes erts: Test compatibility of funs with R12 instead of R11 OTP-8531 bg/compiler-remove-r11-support
2010-03-22compiler: Don't support the no_binaries optionBjörn Gustavsson
The no_binaries option terminates the compiler with an error if any bit syntax is used in the module being compiled. (It used to be implied by the removed r11 option.)
2010-03-22compiler: Don't support the no_constant_pool optionBjörn Gustavsson
The no_constant_pool option was implied by the r11 option. It turns off the usage of the constant (literal) pool, so that BEAM instructions that use constants can be loaded in an R11 system. Since the r11 option has been removed, there is no need to retain the no_constant_pool option.
2010-03-22compiler: Don't support the r11 optionBjörn Gustavsson
The r11 option was used to generate BEAM modules that could loaded both on both R11 and R12/R13 to facilitate testing that R11 and R13 nodes could communicate with each other. Since R14 is only required to be compatible with R12 and R13 nodes, the r11 option is no longer needed.
2009-11-20The R13B03 release.OTP_R13B03Erlang/OTP