aboutsummaryrefslogtreecommitdiffstats
path: root/lib/stdlib/test/erl_eval_SUITE.erl
AgeCommit message (Collapse)Author
2016-03-09Remove ?line macrosBjörn Gustavsson
While we are it, also re-ident the files.
2016-03-09Eliminate 'suite' and 'doc' clausesBjörn Gustavsson
2016-03-09Eliminate use of test_server:fail/0,1Björn Gustavsson
2016-03-09Modernize 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.
2016-01-13stdlib: fix erl_eval not using non-local function handlerHans Bolinder
See also ERL-32 at bugs.erlang.org. Thanks to Ben Paxton.
2015-10-19Use full list of bindings when matching on map keysJosé Valim
Prior to this patch, the following code would not eval: X = key, (fun(#{X := value}) -> true end)(#{X => value}) That's because the key evaluation was using the new list of bindings introduced on every anonymous fun. Since keys only match on values defined prior to the pattern and do not introduce any new binding, we must use the full and original list of binding.
2015-06-18Change license text to APLv2Bruce Yinhe
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.
2014-08-26stdlib: 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-15Fix evaluation of empty map patterns in erl_lintAnthony Ramine
Reported-by: José Valim
2014-03-14Fix evaluation of empty map updates in erl_evalAnthony Ramine
2014-02-24Merge branch 'josevalim/jv-eval-guards/OTP-11747'Henrik Nord
* josevalim/jv-eval-guards/OTP-11747: Fix erl_eval bug when erlang:'=='/2 is used in guards
2014-02-01Handle map fields in their own function in erl_evalAnthony Ramine
Map fields (K := V, K => V) are not expressions and shouldn't be clauses of erl_eval:expr/5.
2014-01-23Fix erl_eval bug when erlang:'=='/2 is used in guardsJosé Valim
Prior to this commit, erl_eval did not properly evaluate erlang:'=='/2 and friends in guard clauses because it always flattened it to a local call ==/2. This commit removes the flattening logic while still normalizing old guards style.
2013-12-12Test named funsAnthony Ramine
2013-04-19Remove the "coding: utf-8" comment from all Erlang source filesHans Bolinder
2013-04-17Encode Erlang source files with non-ascii characters in UTF-8Björn Gustavsson
To ensure that 'master' compiles when we merge 'maint' to it, regardless of which encoding is default in 'master', all source files with non-ascii characters *must* have the encoding specified.
2013-02-10erl_eval: Don't allow evaluation of {M,F} in the shellBjörn Gustavsson
Tuples funs were removed in de7e01c958ff7c9e6da4034a53567a30a4ae5792, but it was still possible to evaluate tuple funs in the shell.
2013-02-07[stdlib] Fix bugs in eval_bitsHans Bolinder
Unicode related.
2013-01-10erl_eval: Don't test parameterized modulesBjörn Gustavsson
2012-08-17Remove support for tuple funsBjörn Gustavsson
Tuple funs were deprecated in R15B (in commit a4029940e309518f5500).
2012-03-30Update copyright yearsBjörn-Egil Dahlberg
2012-01-27erl_eval_SUITE: Skip test of parameterized modules if native codeBjörn Gustavsson
Parameterized modules are not supported by HiPE.
2011-11-07EEP-23: Allow variables in fun M:F/ABjörn Gustavsson
Currently, the external fun syntax "fun M:F/A" only supports literals. That is, "fun lists:reverse/1" is allowed but not "fun M:F/A". In many real-life situations, some or all of M, F, A are not known until run-time, and one is forced to either use the undocumented erlang:make_fun/3 BIF or to use a "tuple fun" (which is deprecated). EEP-23 suggests that the parser (erl_parse) should immediately transform "fun M:F/A" to "erlang:make_fun(M, F, A)". We have not followed that approach in this implementation, because we want the abstract code to mirror the source code as closely as possible, and we also consider erlang:make_fun/3 to be an implementation detail that we might want to remove in the future. Instead, we will change the abstract format for "fun M:F/A" (in a way that is not backwards compatible), and while we are at it, we will move the translation from "fun M:F/A" to "erlang:make_fun(M, F, A)" from sys_pre_expand down to the v3_core pass. We will also update the debugger and xref to use the new format. We did consider making the abstract format backward compatible if no variables were used in the fun, but decided against it. Keeping it backward compatible would mean that there would be different abstract formats for the no-variable and variable case, and tools would have to handle both formats, probably forever. Reference: http://www.erlang.org/eeps/eep-0023.html
2011-08-31Improve and correct types and specifications in Kernel and STDLIBHans Bolinder
Running Dialyzer on the test suites revealed a few type errors.
2011-05-12Types and specifications have been modified and addedHans Bolinder
2011-03-23v3_core: Fix variable incorrectly unbound after binary matchBjörn Gustavsson
In the following code: m(<<Sz:8,_:Sz/binary>>) -> Sz = wrong. the Sz variable is supposed to be bound in the function header and the matching "Sz = wrong" should cause a badarg exception. But what happens is that the Sz variables seems to be unbound and the matching succeds and the m/1 function returns 'wrong'. If the Sz variable is used directly (not matched), it will have the expected value. Thus the following code: m(<<Sz:8,_:Sz/binary>>) -> Sz. will correctly return the value of Sz that was matched out from the binary. Reported-by: Bernard Duggan
2011-03-11Update copyright yearsBjörn-Egil Dahlberg
2011-02-17Rename Suite Callback to Common Test HookLukas Larsson
2011-02-17Fix formatting for stdlibLukas 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 stdlib tests to conform with common_test standardLukas Larsson
2011-02-17Update all fin_per_testcase to end_per_testcase.Lukas Larsson
2010-12-21Fix type-checking of variable used in zero-width bit syntax constructionBjörn Gustavsson
<<A:0>> will always produce an empty binary, regardless of the type of A. The bug is in the run-time system. Fix it so that a non-numeric value for A will cause a badarg exception. Reported-by: Zvi
2009-11-20The R13B03 release.OTP_R13B03Erlang/OTP