aboutsummaryrefslogtreecommitdiffstats
path: root/lib/compiler/test/match_SUITE.erl
AgeCommit message (Collapse)Author
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-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