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