aboutsummaryrefslogtreecommitdiffstats
path: root/lib/compiler/test/match_SUITE.erl
AgeCommit message (Collapse)Author
2016-08-19Strengthen test case added in 8b83bc0bBjörn Gustavsson
Don't only test the case that failed; test it exhaustively.
2016-07-12compiler: Test literal binary matchingBjörn-Egil Dahlberg
The following regression was introduced in 19.0: foo(bar, <<"x">>) -> 1; foo(_, <<"x">>) -> 2; foo(_, <<"y">>) -> 3; foo(_, _) -> fail. The call foo(bar,<<"y">>) would errorneous return 'fail' instead of 3. A testcase in match_SUITE has been added to verify this.
2016-05-23v3_core: Don't depend on sys_core_fold for cleaning upBjörn Gustavsson
a3ec2644f5 attempted to teach v3_core not to generate code with unbound variables. The approach taken in that commit is to discard all expressions following a badmatch. That does not work if the badmatch is nested: {[V] = [] = foo,V}, V That would be rewritten to: {error({badmatch,foo})}, V where V is unbound. If we were to follow the same approach, the tuple construction code would have to look out for a badmatch. As would list construction, begin...end, and so on. Therefore, as it is impractical to discard all expressions that follow a badmatch, the only other solution is to ensure that the variables that the pattern binds will somehow be bound. That can be arranged by rewriting the pattern to a pattern that binds the same variables. Thus: error({badmatch,foo}), E = foo, case E of {[V],[]} -> V; Other -> error({badmatch,Other} end
2016-04-28v3_core: Don't depend on sys_core_fold for cleaning upBjörn Gustavsson
v3_core would generate unsafe code for the following example: f() -> {ok={error,E}} = foo(), E. Internally, the code would look similar to: f() -> Var = foo(), error({badmatch,Var}), E. That is, there would remain a reference to an unbound variable. Normally, sys_core_fold would remove the reference to 'E', but if if optimization was disabled the compiler would crash.
2016-04-27Move pattern-matching tests to match_SUITEBjörn Gustavsson
2016-03-15update copyright-yearHenrik Nord
2016-02-25Remove ?line macrosBjörn Gustavsson
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-11-10Cover sys_pre_expand:pattern/2Björn Gustavsson
2015-06-18Change license text to APLv2Bruce Yinhe
2015-03-09v3_core: Teach pat_alias/2 to eliminate duplicated variablesBjörn Gustavsson
Duplicated variables as aliases in patterns, such as: f({_,_}=Dup=Dup) -> ... will work, but produce sub-optimal code similar to: f({_,_}=Dup=NewVar) when Dup =:= NewVar -> ... with one extra guard test for each duplicated variable. Rewrite pat_alias/2 to eliminate all duplicated variables. While we are at it, also simplify handling of tuples, conses, and literals by using the data functions in the cerl module.
2015-02-03Merge branch 'maint'Björn Gustavsson
* maint: Update primary bootstrap Be more careful about map patterns when evalutating element/2 Do not convert map patterns to map expressions Conflicts: bootstrap/lib/compiler/ebin/sys_core_fold.beam lib/compiler/test/match_SUITE.erl
2015-02-03Do not convert map patterns to map expressionsBjörn Gustavsson
In code such as: case {a,Map} of {a,#{}}=T -> T end we must NOT rewrite a map pattern to a map expression like this: case Map of #{} -> {a,#{}} end because the pattern '#{}' will match any map, but the expression '#{}' will construct an empty map.
2015-01-29Merge branch 'bjorn/compiler/map-fixes'Björn Gustavsson
* bjorn/compiler/map-fixes: cerl: Remove a clause in fold_map_pairs/3 that will never be reached Move grouping of map constructions from v3_core to v3_kernel core_pp: Correct printing of map literals Strengthen and modernize compile_SUITE core_parse: Always fold literal conses cerl: Make sure that we preserve the invariants for maps cerl_clauses: Fix indentation sys_core_fold: Strengthen optimization of letrecs in effect context Fix handling of binary map keys in comprehensions core_lib: Teach is_var_used/2 to handle keys in map patterns warnings_SUITE: Eliminate compiler warning for a shadowed variable lc_SUITE: Add shadow/1 Modernize lc_SUITE
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.
2015-01-26core_lib: Teach is_var_used/2 to handle keys in map patternsBjörn Gustavsson
is_var_used/2 did not notice that variable keys in map patterns were used, which could cause sys_core_fold to do unsafe optimizations.
2015-01-14sys_core_fold: Correct optimization of 'case'Björn Gustavsson
The optimization of a 'case' statement could lead to incorrect code that would cause an exception at run-time. Here is an example to show how the optimization went wrong. Start with the following code: f({r,#{key:=Val},X}=S) -> case S of {r,_,_} -> setelement(3, Val, S) end. (The record operations have already been translated to the corresponding tuple operations.) The first step in case_opt/3 is to substitute S to obtain: f({r,#{key:=Val},X}=S) -> case {r,#{key:=Val},X} of {r,_,_} -> setelement(3, Val, S) end. After that substitution the 'case' can be simplified to: f({r,#{key:=Val},_}=S) -> case #{key:=Val} of NewVar -> setelement(3, Val, S) end. That is the result from case_opt/3. Now eval_case/2 notices that since there is only one clause left in the 'case', the 'case' can eliminated: f({r,#{key:=Val},_}=S) -> NewVar = #{key:=Val}, setelement(3, Val, S). Since the map construction may have a side effect, it was not eliminated, but assigned to a variable that is never used. The problem is that '#{key:=Val}' is fine as a pattern, but in a construction of a new map, the '=>' operator must be used. So the map construction will fail, generating an exception. As a conservative correction for a maintenance release, we will abort the 'case' optimization if the substitution into the 'case' expression is anything but data items (tuples, conses, or literals) or variables. Reported-by: Dmitry Aleksandrov
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.
2011-04-12match_SUITE: Cover a clause in beam_dead:forward/4Björn Gustavsson
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-03-11Update copyright yearsBjörn-Egil Dahlberg
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-05-20v3_core tests: Cover handling of pattern aliasesBjörn Gustavsson
2010-04-27Merge branch 'bg/compiler-suppress-result-ignored' into devErlang/OTP
* bg/compiler-suppress-result-ignored: compiler tests: Eliminate "result of expression is ignored" warnings Silence warnings for expressions that are assigned to "_" OTP-8602 bg/compiler-suppress-result-ignored It is now possible to suppress the warning in code such as "list_to_integer(S), ok" by assigning the ignored value "_" like this: "_ = list_to_integer(S), ok".
2010-04-15Silence warnings for expressions that are assigned to "_"Björn Gustavsson
There is currently no zero-cost way to silence the warning "the result of the expression is ignored", which is issued for code such as: list_to_integer(S), ok Such code can be useful for assertions or input validation. Teach the compiler to silence the warning for expressions that are explicitly assigned to to the "_" variable, such as: _ = list_to_integer(S), ok Implement it by having the v3_core pass annotate calls in Core Erlang like this: let <_> = ( call 'erlang':'list_to_integer'(S) -| ['result_not_wanted'] ) in 'ok' and modifiy sys_core_fold to suppress the warning for any call having the annotation. We deliberately do not make it possible to silence the warnings for expressions like: {build,an,unnecessary,term}, ok or is_list(L), ok because we don't know of any real-world scenarios in which that would be useful.
2009-11-20The R13B03 release.OTP_R13B03Erlang/OTP