aboutsummaryrefslogtreecommitdiffstats
path: root/lib/compiler/test/map_SUITE.erl
AgeCommit message (Collapse)Author
2016-02-25Eliminate use of test_server:fail/0,1Björn Gustavsson
2016-01-13Merge branch 'maint'Björn Gustavsson
* maint: Fix crash when attempting to update a fun as if it were a map
2016-01-12Fix crash when attempting to update a fun as if it were a mapBjörn Gustavsson
The following example would cause an internal consistency failure in the compiler: f() -> ok. update() -> (fun f/0)#{u => 42}. The reason is that internally, v3_core will (incorrectly) rewrite update/0 to code similar to this: update() -> if is_map(fun f/0) -> maps:update(u, 42, fun f/0) end. Since funs are not allowed to be created in guards, incorrect and unsafe code would be generated. It is easy to fix the bug. There already is a is_valid_map_src/1 function in v3_core that tests whether the argument for the map update operation can possibly be a valid map. A fun is represented as a variable with a special name in Core Erlang, so it would not be recognized as unsafe. All we'll need to do to fix the bug is to look closer at variables to ensure they don't represent funs. That will ensure that the code is rewritten in the correct way: update() -> error({badmap,fun f/0}) end. Reported-by: Thomas Arts
2015-12-11compiler tests: Replace 'random' with 'rand'Björn Gustavsson
2015-09-04compiler: Add test for corrupt register in get_map_elementsBjörn-Egil Dahlberg
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.
2015-04-13map_SUITE: Add tests of is_map/1 with literal mapsBjörn Gustavsson
To be sure that the compiler and BEAM virtual machine correctly handles literals maps, we must test it.
2015-03-30compiler: Strengthen Maps testsBjörn-Egil Dahlberg
2015-03-27compiler: Strengthen Maps testsBjörn-Egil Dahlberg
2015-03-12compiler: Fix map_SUITE:t_map_sort_literal for new map compare orderSverker Eriksson
where key 1 is less than key 1.0
2015-02-18map_SUITE: Cover comparisons of 'nil' in v3_codegenBjörn Gustavsson
2015-01-28core_pp: Correct printing of map literalsBjörn Gustavsson
A map key in a pattern would be incorrectly pretty-printed. As an example, the pattern in: x() -> #{ #{ a => 3 } := 42 } = X. would be pretty-printed as: <~{~<~{~<'a',3>}~,42>}~ instead of: <~{~<~{::<'a',3>}~,42>}~ When this problem has been corrected, the workaround for it in cerl:ann_c_map/3 can be removed. The workaround was not harmless, as it would cause the following map update to incorrectly succeed: (#{})#{a:=1}
2015-01-21map_SUITE: Ensure recompilation when running coverBjörn Gustavsson
2014-10-02compiler: Update test for Maps aliasingBjörn-Egil Dahlberg
2014-08-26compiler: Update Map testsBjörn-Egil Dahlberg
2014-04-03compiler,stdlib: Fix Map literals as keys for Maps in patternsBjörn-Egil Dahlberg
2014-03-25compiler: Do not evaluate map expressions with bad keysBjörn-Egil Dahlberg
Map keys with large (non literal) binary keys must fail.
2014-03-25compiler: Strengthen Maps warnings testsBjörn-Egil Dahlberg
Increases coverage.
2014-03-24compiler: Test deep map structureBjörn-Egil Dahlberg
2014-03-24compiler: Cover #{ [] => Var } in testcaseBjörn-Egil Dahlberg
Coverage removed by literals.
2014-03-18Properly collect variables in map expressions in v3_coreAnthony Ramine
Reported-by: José Valim
2014-03-07Merge branch 'nox/maps-beam_jump-put_map'Björn-Egil Dahlberg
* nox/maps-beam_jump-put_map: Properly collect labels in put_map instructions in beam_jump
2014-03-06Merge branch 'nox/maps-beam_jump'Björn-Egil Dahlberg
* nox/maps-beam_jump: Properly check label use in get_map_elements in beam_jump
2014-03-06Merge branch 'nox/maps-v3_codegen-sort-nil-keys'Björn-Egil Dahlberg
* nox/maps-v3_codegen-sort-nil-keys: Properly sort map pairs in v3_codegen
2014-03-06Properly collect labels in put_map instructions in beam_jumpAnthony Ramine
Reported-by: Ulf Norell
2014-03-05Properly check label use in get_map_elements in beam_jumpAnthony Ramine
Reported-by: Ulf Norell
2014-03-04Properly order Kernel code for maps with mixed pairsAnthony Ramine
The Kernel instructions were not properly ordered when compiling maps with complex values mixed in assoc and exact pairs. Reported-by: Ulf Norell
2014-03-04Properly sort map pairs in v3_codegenAnthony Ramine
Literal nil values aren't tagged tuple but the bare atom nil. The function lists:sort/2 expects the passed function to return true if the first element is less than or equal to the second, not strictly less than. The original base clause is changed accordingly. Reported-by: Ulf Norell
2014-03-04Merge branch 'nox/maps-fix-beam_bool-put_map'Björn-Egil Dahlberg
* nox/maps-fix-beam_bool-put_map: Properly collect labels in put_map instructions in beam_bool
2014-03-04Merge branch 'nox/maps-expand-update'Björn-Egil Dahlberg
* nox/maps-expand-update: Fix expansion of map update arguments
2014-03-03Properly collect labels in put_map instructions in beam_boolAnthony Ramine
Reported-by: Ulf Norell
2014-03-01Fix expansion of map update argumentsAnthony Ramine
Reported-by: José Valim
2014-02-21compiler: Update map_SUITE to handle inliningBjörn-Egil Dahlberg
2014-02-20compiler: Strengthen Maps compile testsBjörn-Egil Dahlberg
2014-02-19compiler: Test Maps aliasingBjörn-Egil Dahlberg
2014-02-10Merge branch 'egil/compiler/maps-fix-sys_core_fold'Björn-Egil Dahlberg
* egil/compiler/maps-fix-sys_core_fold: compiler: Fix sys_core_fold let optimization compiler: Add debug listing after sys_core_fold
2014-02-10Merge branch 'egil/compiler/maps-fix-codegen'Björn-Egil Dahlberg
* egil/compiler/maps-fix-codegen: compiler: Fix codegen multiple updates for Maps erts,compiler: Correct and amend tests for Maps
2014-02-07compiler: Fix sys_core_fold let optimizationBjörn-Egil Dahlberg
Map variable was not covered and faulty optimization could occur. Ex. t() -> M0 = id(#{ "a" => 1 }), #{ "a" := _ } = M0, M0#{ "a" := b }. M0 was lost in let expression optimization.
2014-02-07erts,compiler: Correct and amend tests for MapsBjörn-Egil Dahlberg
Faulty test for maps update
2014-02-07compiler: Update map_SUITE with error case testBjörn-Egil Dahlberg
M#{ key := V } should fail when M is not a Map
2014-01-31compiler: Strengthen Maps testsBjörn-Egil Dahlberg