aboutsummaryrefslogtreecommitdiffstats
path: root/lib/compiler/test/compilation_SUITE.erl
AgeCommit message (Collapse)Author
2016-04-27compilation_SUITE: Use explicit exportsBjörn Gustavsson
With 'export_all' it is easy to add a new test case function and forget to add its name to the list of test cases to run. While we are it, remove unused functions and add the forgotten test case on_load_inline/1.
2016-04-27Remove support for running tests on a separate Erlang nodeBjörn Gustavsson
It has not been used for ages.
2016-04-27Move code from compilation_SUITE to beam_block_SUITEBjörn Gustavsson
2016-04-27Move list comprehension tests to lc_SUITEBjörn Gustavsson
2016-04-27Move catch tests to trycatch_SUITEBjörn Gustavsson
2016-04-27Remove compilation_SUITE:long_string/1Björn Gustavsson
long_string/1 was written to test that long string were handled efficiently in beam_asm. Strings used to be stored in the string table chunk, but are currently literals. There does not seem that this test case is likely to find any bugs.
2016-04-27Move pattern-matching tests to match_SUITEBjörn Gustavsson
2016-04-27Move test cases from compilation_SUITE to beam_utils_SUITEBjörn Gustavsson
beam_utils_SUITE didn't exist when the two test cases were written.
2016-04-27Move complex_guard/1 from compilation_SUITE to guard_SUITEBjörn Gustavsson
2016-04-27Remove compilation_SUITE:guards/1Björn Gustavsson
Obsoleted by guard_SUITE (especially literal_type_tests/1).
2016-04-27Move tests from compilation_SUITE to record_SUITEBjörn Gustavsson
2016-04-27Move bit syntax test cases from compilation_SUITE to bs_match_SUITEBjörn Gustavsson
We used to put code that would crash the compiler into compilation_SUITE_data. That way we would have a failing test case to remind us to fix a bug. Nowadays, we generally fix the bug and write the test case at the same time. Therefore it makes more sense to put the test code directly into a test suite. Move out bin_syntax_1 through bin_syntax_5 test cases. Scrap bin_syntax_6 because it does not longer seems to be relevant. While we are it, rename the fun_shadow/1 test to size_shadow/1. Also make sure that the code produces the correct result.
2016-04-27Remove useless test case compilation_SUITE:otp_2141/1Björn Gustavsson
2016-04-27compilation_SUITE: Run the Core linter for all compilationsBjörn Gustavsson
2016-03-15update copyright-yearHenrik Nord
2016-02-25Remove ?line macrosBjörn Gustavsson
2016-02-25Replace use of lists:keysearch/3 with lists:keyfind/3Björn Gustavsson
2016-02-25Eliminate use of doc and suite clausesBjörn Gustavsson
Those clause are obsolete and never used by common_test.
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-25Modernize 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-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-22fix errors caused by changed line numbersBruce Yinhe
2015-06-18Change license text to APLv2Bruce Yinhe
2015-04-29compilation_SUITE: Speed up the self_compile test casesBjörn Gustavsson
It is not necessary to compile the compile three times. After the second compilation, we compare the generated .beam files with the .beam files that were used when compiling them. Doing one more round will not find more bugs. While we are it, remove the ?line macros and the unused make_current/1 function.
2015-04-20compilation_SUITE: Unload tested modules using the code serverBjörn Gustavsson
Don't unload modules using BIFs; use the code server to ensure that code:all_loaded/0 only lists code that is actually loaded.
2015-02-03sys_core_fold: Optimize let statements more aggressivelyBjörn Gustavsson
I originally decided that in 'value' context, rewriting a let statement where the variables were not in the body to a sequence was not worth it, because the variables would be unused in only one let in a thousand lets (roughly). I have reconsidered. The main reason is that if we do the rewrite, core_lib:is_var_used/2 will be used much more frequently, which will help us to find bugs in it sooner. Another reason is that the way letify/2 is currently implemented with its own calls to core_lib:is_var_used/2 is only safe as long as all the bindings are independent of each other. We could make letify/2 smarter, but if we introduce this new optimization there is no need. Measuring compilation speed, I have not seen any significant slowdown. It seems that although core_lib:is_var_used/2 is called much more frequently, most calls will be fast because is_var_used/2 will quickly find a use of the variable. Also add a test case to cover a line opt_guard_try/1 that was no longer covered.
2014-08-07Use +clint0 in compiler's test suitesAnthony Ramine
2014-01-21Fix testing with unicode pathsDan Gudmundsson
re needs unicode option
2013-12-13Test compilation of BEAM assembly with optimisations onAnthony Ramine
2013-11-22Rename otp_8949_a/0 which common_test interprets as an info functionBjörn Gustavsson
Before running a test case named testcase/1, common_test will call testcase/0 (the info function). Exceptions and illegal return values would be silently ignored. In a planned update to common_test, errors will instead cause the test case to fail. The test case otp_8949_a/1 has a helper function called otp_8949_a/0. Rename it to do_otp_8949_a/0. While at it, also fix a copy and paste bug in the list of test cases. otp_8949_a was run twice; otp_8949_b was never run.
2013-02-22Update copyright yearsBjörn-Egil Dahlberg
2013-02-09Fix unsafe optimization of funsBjörn Gustavsson
Commits 53bd4974a101 and 726f6e4c7afe simplified the handling of match_fail (used to generated exceptions such as 'function_clause') by first rewriting them to a call to erlang/error{1,2} and later rewriting them to specialized BEAM instructions (to reduce the code size). There was one flaw, though, which only was exposed when more aggressive optimizations were added in c3b60f86c622. Here is an example to explain it: t(V) -> fun(get) -> V end. The following BEAM code will be initially generated for the fun: {function, '-t/1-fun-0-', 2, 5}. {label,1}. {line,[{location,"t.erl",5}]}. {func_info,{atom,t},{atom,'-t/1-fun-0-'},2}. {label,2}. {test,is_eq_exact,{f,2},[{x,0},{atom,get}]}. {move,{x,1},{x,0}}. return. {label,2}. {test_heap,2,1}. {put_list,{x,0},nil,{x,1}}. {move,{atom,function_clause},{x,0}}. {line,[{location,"t.erl",5}]}. {call_ext_only,2,{extfunc,erlang,error,2}}. Translating back to Erlang code, that would be roughly: '-t/1-fun-0-'(get, V) -> V; '-t/1-fun-0-'(Arg1, _) -> erlang:error(function_clause, [Arg1]). Note that the second argument (the free variable V) is not included in the call to erlang:error/2. The beam_except pass will simplify the code to: {function, '-t/1-fun-0-', 2, 8}. {label,1}. {line,[{location,"t.erl",5}]}. {func_info,{atom,t},{atom,'-t/1-fun-0-'},2}. {label,2}. {test,is_eq_exact,{f,1},[{x,0},{atom,get}]}. {move,{x,1},{x,0}}. return. The code has been shortened by jumping to the func_info/3 instruction. Translating back to Erlang: '-t/1-fun-0-'(get, V) -> V; '-t/1-fun-0-'(Arg1, Arg2) -> erlang:error(function_clause, [Arg1,Arg2]). it is clear that both arguments are now included in the 'function_clause' exception, even though the initially generated code only included the first argument. That is no problem in this particular case, but for some more complex funs, optimizing the first version based on variable usage could make the second version unsafe. I rejected the following potential solutions: - Including the free arguments in the call to erlang:error/2: '-t/1-fun-0-'(get, V) -> V; '-t/1-fun-0-'(Arg1, Arg2) -> erlang:error(function_clause, [Arg1,Arg2]). Unfortunately, that is tricky. The free variables are only known after the second pass in v3_kernel when variable usage has been calculated. We would need to add a third pass (only for funs) that would the free arguments to the second argument for erlang:error/2 *and* update the variable usage information. - Calling beam_except earlier, from within beam_block before any optimizations based on variable usages are done. But means that the problem could reappear in some other form in the future when other updates are done to the code generator and/or optimization passes. The solution I have chosen is to modify beam_except to only replace a call to erlang:error(function_class, Args) if the length of Args is the same as the arity in the func_info/3 instruction. The code will be slightly larger. Also, the free variables for funs and list comprehensions will no longer be included in the function_clause exception (that could be less confusing, but it also means less information during debugging).
2013-01-09compiler: Remove support for packagesBjörn Gustavsson
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-10-09Improve binary matching of literalsBjörn Gustavsson
The bs_match_string instruction is used to speed up matching of binary literals. For example, given this source code: foo1(<<1,2,3>>) -> ok. The matching part of the code will look like: {test,bs_start_match2,{f,1},1,[{x,0},0],{x,0}}. {test,bs_match_string,{f,3},[{x,0},24,{string,[1,2,3]}]}. {test,bs_test_tail2,{f,3},[{x,0},0]}. Nice. However, if we do a simple change to the source code: foo2(<<1,2,3>>) -> ok; foo2(<<>>) -> error. the resulting matching code will look like (sligthly simplified): {test,bs_start_match2,{f,4},1,[{x,0},0],{x,0}}. {test,bs_get_integer2,{f,7},1,[{x,0},{integer,8},1,Flags],{x,1}}. {test,is_eq_exact,{f,8},[{x,1},{integer,1}]}. {test,bs_match_string,{f,6},[{x,0},16,{string,[2,3]}]}. {test,bs_test_tail2,{f,6},[{x,0},0]}. {move,{atom,ok},{x,0}}. return. {label,6}. {bs_restore2,{x,0},{atom,start}}. {label,7}. {test,bs_test_tail2,{f,8},[{x,0},0]}. That is, matching of the first byte is not combined into the bs_match_string instruction that follows. Fix this problem by allowing a bs_match_string instruction to be used if all clauses will match either the same integer literal or the empty binary.
2012-03-30Update copyright yearsBjörn-Egil Dahlberg
2012-02-13compiler: Teach the inliner to preserve on_load functionsBjörn Gustavsson
The inliner was ignorant of on_load functions and would discard them (unless they were exported or referenced). Noticed-by: Yiannis Tsiouris <[email protected]>
2012-01-04compilation_SUITE: Compile compiler modules in parallelBjörn Gustavsson
On my Mac Pro with 8 cores, this change make self_compile/1 more than twice as fast, and self_compile_old_inliner/1 more than 4 times faster.
2012-01-04compilation_SUITE: Prevent cover from being run on slave nodesBjörn Gustavsson
In the self compilation test cases, the compiler compiles itself and runs the newly compiled version on a slave node. Having the cover server starting on the slave node defeats the purpose of the test, since it will load the SAME cover-compiled code on the slave node. (It will also be slower, but will not improve coverage since it compiles the same source files again.) Use a shielded node to prevent the cover server from getting started on the slave node.
2012-01-04Eliminate the match_fail primop in v3_kernel and later passesBjörn Gustavsson
In the v3_life pass, it is assumed that a 'match_fail' primop only occur at the top-level and at the end of a function. But this code: do_split_cases(A) -> case A of x -> Z = dummy1; _ -> Z = dummy2, a=b end, Z. will be optimized by sys_core_fold to the following code: 'split_cases'/1 = fun (_cor0) -> let <_cor7,Z> = case _cor0 of <'x'> when 'true' -> < 'dummy1','dummy1' > <_cor6> when 'true' -> %% Here follows a 'match_fail' primop inside %% multiple return values: < primop 'match_fail'({'badmatch','b'}),'dummy2' > end in Z moving the 'match_fail' primop into a "values" construction. In the future, we would like to get rid of the v3_life pass (it is there for historical reasons), so in the mean-time we prefer to not add more code to it by generalizing the handling of 'match_fail'. Since the 'match_fail' primop can be simulated by erlang:error/{1,2}, the simplest solution is to translate 'match_fail' to a call to erlang:error/{1,2} in v3_kernel and remove the handling of 'match_fail' in v3_life and v3_codegen. It is tempting to get rid of 'match_fail' also in the Core Erlang format, but there are two issues: - Removing the support for 'match_fail' completely may break tools that generate Core Erlang code. We should not do that in a minor release. - There is no easy way to generate a 'function_clause' exception that will remain correct if it will be inlined into another function. (Calling "erlang:error(function_clause, Args)" is fine only if it is not inlined into another function.) A good solution probably involves introducing new instructions, which is better done in a major release. Noticed-by: Håkan Matsson Minimized-test-case-by: Erik Søe Sørensen
2011-04-12compiler tests: Reinstate ?MODULE macro in calls to test_lib:recompile/1Björn Gustavsson
In 3d0f4a3085f11389e5b22d10f96f0cbf08c9337f (an update to conform with common_test), in all test_lib:recompile(?MODULE) calls, ?MODULE was changed to the actual name of the module. That would cause test_lib:recompile/1 to compile the module with the incorrect compiler options in cloned modules such as record_no_opt_SUITE, causing worse coverage.
2011-02-23compiler: Eliminate some warningsBjörn Gustavsson
2011-02-17Rename Suite Callback to Common Test HookLukas Larsson
2011-02-17Fix formatting for compilerLukas Larsson
2011-02-17Add init_per_suite and end_per_suiteLukas Larsson
2011-02-17Add ts_install_scb to suite/0Lukas Larsson
2011-02-17Update compiler tests to conform with common_test standardLukas Larsson
2010-12-02beam_utils: Fix check_liveness/3 for receive loopsBjörn Gustavsson
Sometimes the beam_bool pass wants to know whether an y register will be killed by the code that follows and will do (effectively): beam_utils:is_killed({y,Y}, Code, L) When asked to calculate the liveness for an y register, beam_utils:is_killed/3 will loop forever if the code includes a receive loop. Since this rarely occurs, fix the problem in the simplest and most conservative way. Reported-by: Christopher Williams