aboutsummaryrefslogtreecommitdiffstats
path: root/lib/stdlib/src/erl_eval.erl
AgeCommit message (Collapse)Author
2015-06-18Change license text to APLv2Bruce Yinhe
2015-04-30stdlib: Use module erl_annoHans Bolinder
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-10-03Merge branch 'egil/maps/variable-keys/OTP-12218'Björn-Egil Dahlberg
* egil/maps/variable-keys/OTP-12218: (22 commits) compiler: Update test for Maps aliasing compiler: Properly support Map aliasing compiler: Refactor Map pairs aliasing compiler: Fix harmless need_heap error for Maps stdlib: Update Map tests stdlib: Use environment bindings for Maps keys in erl_eval matching debugger: Update Map tests compiler: Update Map tests compiler: Fix v3_core Maps pair chains compiler: Use expressions in core patterns compiler: Use variables in Map cerl inliner compiler: Reintroduce binary limit for Map keys compiler: Shameless v3_core hack for variables compiler: Use variables in Map beam assmebler compiler: Use variables in Map kernel pass compiler: Use variables in Map core pass compiler: Normalize unary ops on Maps key literals stdlib: Update Map tests stdlib: erl_lint Map key variables compiler: Maps are always patterns never values in matching ...
2014-08-26stdlib: Use environment bindings for Maps keys in erl_eval matchingBjörn-Egil Dahlberg
2014-07-07Merge branch 'mururu/fix-typo' into maintBruce Yinhe
* mururu/fix-typo: Fix typo in erl_eval:exprs comments
2014-07-04Fix typo in erl_eval:exprs commentsYuki Ito
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-28erts,stdlib: Change map module name to mapsBjörn-Egil Dahlberg
Name conforms to EEP.
2014-01-28stdlib: Teach erl_eval Maps ':=' exact operatorBjörn-Egil Dahlberg
2014-01-28erl_eval: Add functions to interpreter for mapsBjörn-Egil Dahlberg
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-12Support named funs in the shellAnthony Ramine
The current code for the evaluation of ordinary funs is dependent on the order on variables in the fun environment as returned by erlang:fun_info(Fun, env). To avoid the problem in the future, make sure that we only have one free variable in the funs that we will need to inspect using erlang:fun_info(Fun, env).
2013-09-12Remove ^L characters hidden randomly in the code. Not those used in text ↵Pierre Fenoll
files as delimiters. While working on a tool that processes Erlang code and testing it against this repo, I found out about those little sneaky 0xff. I thought it may be of help to other people build such tools to remove non-conforming-to-standard characters.
2013-05-28Fix receive support in erl_eval with a BEAM moduleAnthony Ramine
Using the low-level BEAM instructions, we can loop over each message in the process queue and removes the first message that matches, without receiving them all to later send them back to itself. The function prim_eval:'receive'/2 is equivalent to the following pseudo-code: 'receive'(F, T) -> RESET MESSAGE QUEUE POINTER, LOOP: case PEEK CURRENT MESSAGE WITH TIMEOUT T of {ok,Msg} -> case F(Msg) of nomatch -> DECREMENT TIMEOUT T, ADVANCE MESSAGE QUEUE POINTER, GOTO LOOP; Result -> RESET MESSAGE QUEUE POINTER, Result end; timeout -> RESET MESSAGE QUEUE POINTER, timeout end. To not break Dialyzer and other tools, we use a stub Erlang module which abstract code is forcefully inserted into prim_inet.erl afterwards compilation.
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-01-25Update copyright yearsBjörn-Egil Dahlberg
2013-01-09erl_eval: Remove support for packagesBjörn Gustavsson
2012-01-26erl_eval: Remove support for is_constant/1Björn Gustavsson
2011-11-29erl_eval: Eliminate use of tuple funsBjörn Gustavsson
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-16Fix binary matching in the debuggerBjörn Gustavsson
'eval_bits' is a common utility module used for evaluting binary construction and matching. The functions that do matching (match_bits/{6,7} and bin_gen/6) are supposed to treat the bindings as an abstract data type, but they assume that the bindings have the same representation as in the erl_eval module. That may cause binary matching to fail in the debugger, because the debugger represents the bindings as an unordered list of two-tuples, while the erl_eval modules uses an ordered list of two-tuple (an ordset). One way to fix the problem would be to let the debugger to use ordered lists to represent the bindings. Unfortunately, that would also change how the bindings are presented in the user interface. Currently, the variable have most been recently assigned is shown first, which is convenient. Fix the matching problem by mending the leaky abstraction in eval_bits. The matching functions needs to be passed two additional operations: one for looking up a variable in the bindings and one for adding a binding. Those operations could be passed as two more funs (in addition to the evaluation and match fun already passed), but the functions already have too many arguments. Therefore, change the meaning of the match fun, so that the first argument is the operation to perform ('match', 'binding', or 'add_binding') and second argument is a tuple with arguments for the operation.
2011-05-23Fix a spec and a typeHans Bolinder
A specification that could cause problems for Dialyzer has been fixed. An opaque type in erl_eval has been turned in to a ordinary type. This is a temporary fix.
2011-05-12Types and specifications have been modified and addedHans Bolinder
2009-11-20The R13B03 release.OTP_R13B03Erlang/OTP