aboutsummaryrefslogtreecommitdiffstats
path: root/lib/compiler/test/map_SUITE.erl
AgeCommit message (Collapse)Author
2018-04-29Introduce is_map_key/2 guard BIFMichał Muskała
This complements the `map_get/2` guard BIF introduced in #1784. Rationale. `map_get/2` allows accessing map fields in guards, but it might be problematic in more complex guard expressions, for example: foo(X) when map_get(a, X) =:= 1 or is_list(X) -> ... The `is_list/1` part of the guard could never succeed since the `map_get/2` guard would fail the whole guard expression. In this situation, this could be solved by using `;` instead of `or` to separate the guards, but it is not possible in every case. To solve this situation, this PR proposes a `is_map_key/2` guard that allows to check if a map has key inside a guard before trying to access that key. When combined with `is_map/1` this allows to construct a purely boolean guard expression testing a value of a key in a map. Implementation. Given the use case motivating the introduction of this function, the PR contains compiler optimisations that produce optimial code for the following guard expression: foo(X) when is_map(X) and is_map_key(a, X) and map_get(a, X) =:= 1 -> ok; foo(_) -> error. Given all three tests share the failure label, the `is_map_key/2` and `is_map/2` tests are optimised away. As with `map_get/2` the `is_map_key/2` BIF is allowed in match specs.
2018-04-25Merge branch 'map-get-bif' of git://github.com/michalmuskala/otpBjörn Gustavsson
* 'map-get-bif' of git://github.com/michalmuskala/otp: Introduce map_get guard-safe function OTP-15037
2018-04-24Introduce map_get guard-safe functionMichał Muskała
Rationale Today all compound data types except for maps can be deconstructed in guards. For tuples we have `element/2` and for lists `hd/1` and `tl/1`. Maps are completely opaque to guards. This means matching on maps can't be abstracted into macros, which is often done with repetitive guards. It also means that maps have to be always selected whole from ETS tables, even when only one field would be enough, which creates a potential efficiency issue. This PR introduces an `erlang:map_get/2` guard-safe function that allows extracting a map field in guard. An alternative to this function would be to introduce the syntax for extracting a value from a map that was planned in the original EEP: `Map#{Key}`. Even outside of guards, since this function is a guard-BIF it is more efficient than using `maps:get/2` (since it does not need to set up the stack), and more convenient from pattern matching on the map (compare: `#{key := Value} = Map, Value` to `map_get(key, Map)`). Performance considerations A common concern against adding this function is the notion that "guards have to be fast" and ideally execute in constant time. While there are some counterexamples (`length/1`), what is more important is the fact that adding those functions does not change in any way the time complexity of pattern matching - it's already possible to match on map fields today directly in patterns - adding this ability to guards will niether slow down or speed up the execution, it will only make certain programs more convenient to write. This first version is very naive and does not perform any optimizations.
2018-04-18core_lint: Handle repeated variables in map patterns correctlyBjörn Gustavsson
Keys in map patterns are input variables, not pattern variables.
2017-12-13map_SUITE: Cover beam_utils:bif_to_test/3Björn Gustavsson
2017-01-25Update test cases for erlang:hash/2 removalBjörn-Egil Dahlberg
2016-06-02Eliminate crash for map updates in guardsBjörn Gustavsson
beam_validator would complain that x(1) is uninitialized in a test_heap instruction when attempting to compile the following code with sys_core_fold turned off: foo(M) when not (M#{true := 0}); [M] -> ok. Simplified, the generated BEAM assembly code looked like this: test is_map BadMap x(0) put_map_exact Fail x(0) => x(1) ... jump BooleanStuff BadMap: move ok => x(1) jump Fail BooleanStuff: ... move Boolean => x(2) jump Build Fail: move false => x(2) Build: test_heap 2 3 %% x(0), x(1), x(2) must be live. ... That is, if put_map_exact failed, control would transfer to the label Fail without initializing x(1). Fix that by making sure that x(1) is initilized even if put_map_exact fails: test is_map BadMap x(0) put_map_exact BadLbl x(0) => x(1) ... jump OkLbl BadLbl: move ok => x(1) jump Fail OkLbl: jump BooleanStuff BadMap: move ok => x(1) jump Fail BooleanStuff: ... move Boolean => x(2) jump Build Fail: move false => x(2) Build: test_heap 2 3 %% x(0), x(1), x(2) must be live. ... Note that this situation is rare, and that other optimization passes (beam_dead and beam_jump in particular) will clean up this mess.
2016-05-25v3_codegen: Don't confuse beam_validatorBjörn Gustavsson
Generate code that not only is safe, but can easily be seen by beam_validator to be safe.
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