aboutsummaryrefslogtreecommitdiffstats
path: root/lib/compiler/src/v3_core.erl
AgeCommit message (Collapse)Author
2015-01-29Move grouping of map constructions from v3_core to v3_kernelBjörn Gustavsson
When translating a function with map construction: f(A) -> B = b, C = c, #{A=>1,B=>2,C=>3}. v3_core would break apart the map construction into three parts because of the way the map instructions in BEAM work -- variable keys need to be in their own instruction. In the example, constant propagation will turn two of the keys to literal keys. But the initial breaking apart will not be undone, so there will still be three map constructions: 'f'/1 = fun (_cor0) -> let <_cor3> = ~{::<_cor0,1>}~ in let <_cor4> = ~{::<'b',2>|_cor3}~ in ~{::<'c',3>|_cor4}~ It would be possible to complicate the sys_core_fold pass to regroup map operations so that we would get: 'f'/1 = fun (_cor0) -> let <_cor3> = ~{::<_cor0,1>}~ in ~{::<'b',2>,::<'c',3>|_cor3}~ A simpler way that allows to simplify the translation is to skip the grouping in v3_core and translate the function to: 'f'/1 = fun (_cor0) -> ~{::<_cor0,1>,::<'b',2>,::<'c',3>}~ We will then let v3_kernel do the grouping while translating from Core Erlang to Kernel Erlang.
2015-01-26cerl: Make sure that we preserve the invariants for mapsBjörn Gustavsson
Maps have certain invariants that must be preserved: (1) A map as a pattern must be represented as #c_map{} record, never as a literal. The reason is that the pattern '#{}' will match any map, not just the empty map. The literal '#{}' will only match the empty map. (2) In a map pattern, the key must be a literal, a variable, or data (list or tuple). Keys that are binaries or maps *must* be represented as literals. (3) Maps in expressions should be represented as literals if possible. Nothing is broken if this invariant is broken, but the generated code will be less efficient. To preserve invariant (1), cerl:update_c_map/3 must never collapse a map to a literal. To preserve invariant (3), cerl:update_c_map/3 must collapse a map to a literal if possible. To preserve both invariants, we need a way for cerl:update_c_map/3 to know whether the map is used as a pattern or as an expression. The simplest way is to have an 'is_pat' boolean in the #c_map{} record which is set when a #c_map{} record is initially created. We also need to update core_parse.yrl to establish the invariants in the same way as v3_core, to ensure that compiling from a .core file will work even if all optimizations on Core Erlang are disabled.
2015-01-26Fix handling of binary map keys in comprehensionsBjörn Gustavsson
The translation of list comprehension with a map pattern with a big literal binary as key such as: lc(L) -> [V || #{<<2:301>> := V} <- L]. would generate Core Erlang code where an unbound variable were referenced: 'lc'/1 = fun (L) -> letrec 'lc$^0'/1 = fun (_cor4) -> case _cor4 of <[~{~<_cor1,V>}~|_cor3]> when 'true' -> let <_cor5> = apply 'lc$^0'/1(_cor3) in [V|_cor5] <[_cor2|_cor3]> when 'true' -> apply 'lc$^0'/1(_cor3) <[]> when 'true' -> [] end in let <_cor1> = #{#<2>(301,1,'integer',['unsigned'|['big']])}# in apply 'lc$^0'/1(L) In the map pattern in the 'case' in the 'letrec', the key is the variable '_cor1' which should be bound in the enclosing environment. It is not. There is binding of '_cor1', but in the wrong place (at the end of the function). Because of the way v3_kernel translates letrecs, the code *happens* to work. The code will break if Core Erlang optimizations were strengthened to more aggressively eliminate variable bindings that are not used, or if the translation from Core Erlang to Kernel Erlang were changed. Correct the translation so that '_cor1' is bound in the environment enclosing the 'letrec': 'lc'/1 = fun (L) -> let <_cor1> = #{#<2>(301,1,'integer',['unsigned'|['big']])}# in letrec 'lc$^0'/1 = fun (_cor4) -> case _cor4 of <[~{~<_cor1,V>}~|_cor3]> when 'true' -> let <_cor5> = apply 'lc$^0'/1(_cor3) in [V|_cor5] <[_cor2|_cor3]> when 'true' -> apply 'lc$^0'/1(_cor3) <[]> when 'true' -> [] end in apply 'lc$^0'/1(L) Unfortunately I was not able to come up with a test case that demonstrates the bug.
2014-11-17Merge branch 'maint'Björn Gustavsson
* maint: Fix miscompilation when module contains multiple named funs Fix locations of shadowing warnings in ms_transform
2014-10-27Extract annotations from filter qualifiers in a type-friendly wayBjörn Gustavsson
Commit 78ce8917d started to use get_anno/1 to extract the line annotation from filter qualifiers in comprehensions, but this does not respect the spec of this function and resuls in a dialyzer warning. To make the code more type-friendly, introduce a get_qual_anno/1 function. Kostis Sagonas suggested that the function should be implemented similar to this to also ensure that the qualifiers are of the appropriate form: get_qual_anno({call,Line,_,_}) -> Line; get_qual_anno({op,Line,_,_,_}) -> Line; . . . get_qual_anno({var,Line,_}) -> Line. The problem is that it is difficult to know exacly which forms that may occur and the function will need to be updated if new abstract forms are added. Thus this implementation would complicate maintanance without any real payoff. Reported-by: Kostis Sagonas
2014-10-27Fix miscompilation when module contains multiple named funsAnthony Ramine
A module containing two named funs bearing the same name and arity could be miscompiled. Reported-by: Sam Chapin
2014-10-02compiler: Properly support Map aliasingBjörn-Egil Dahlberg
Matching of type: #{K := V1} = #{K := V2} = M, Will alias (coalesce) to #{K := V1 = V2} = M.
2014-10-01compiler: Refactor Map pairs aliasingBjörn-Egil Dahlberg
2014-08-26compiler: Fix v3_core Maps pair chainsBjörn-Egil Dahlberg
Check for literals instead of variables when constructing chains.
2014-08-26compiler: Use expressions in core patternsBjörn-Egil Dahlberg
Two patterns, binary_segment size and map_pair key, are expressions even in matching. If only bound variables are used we are fine but some expressions which appears as literals needs to be lifted. Currently only Map key binaries will use this.
2014-08-26compiler: Reintroduce binary limit for Map keysBjörn-Egil Dahlberg
2014-08-26compiler: Shameless v3_core hack for variablesBjörn-Egil Dahlberg
2014-08-22compiler: Use variables in Map core passBjörn-Egil Dahlberg
2014-06-17[dialyzer] Use the option 'dialyzer' to control the compilerHans Bolinder
2014-06-17[dialyzer] Fix handling of literal recordsHans Bolinder
This ticket is about records in Erlang code, and when to check the fields against the (optional) types given when defining records. Dialyzer operates on the Erlang Core format, where there are no trace of records. The fix implemented is a Real Hack: Given the new option 'dialyzer' erl_expand_records marks the line number of records in a way that is undone by v3_core, which in turn inserts annotations that can be recognized by Dialyzer.
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: Throw 'nomatch' on matching with bad binary keysBjörn-Egil Dahlberg
Even if a binary key is written as a literal the compiler may choose to make an expression. Emit a warning in those cases and saying the case will not match. This is a limitation in current implementation.
2014-03-18Properly collect variables in map expressions in v3_coreAnthony Ramine
Reported-by: José Valim
2014-03-17compiler: Transform M#{} to is_map(M)Björn-Egil Dahlberg
Core should not understand M#{} Instead transform M#{} to case _cor0 of <_cor1> when call 'erlang':'is_map' (_cor0) -> _cor1 ( <_cor2> when 'true' -> primop 'match_fail' ('badarg') -| ['compiler_generated'] ) end
2014-03-17compiler: Validate Map srcBjörn-Egil Dahlberg
Reject all expressions that are known to fail. Emit 'badarg' for those expressions. Ex. []#{ a => 1} Is not a valid map update expression.
2014-03-14compiler: Create literal Maps in creation if possibleBjörn-Egil Dahlberg
2014-03-06Merge branch 'nox/compiler/v3_core-comprehension-no-export'Björn Gustavsson
* nox/compiler/v3_core-comprehension-no-export: Do not export variables from comprehension cases in v3_core OTP-11770
2014-03-05Do not export variables from comprehension cases in v3_coreAnthony Ramine
Code like the following snippet could make the compiler crash: f() -> [X = a || false] ++ [X = a || false]. Reported-by: Ulf Norell
2014-03-05Compile BIF calls and operator expressions to Core the same wayAnthony Ramine
Previously, erlang:'or'(X, Y) and X or Y were not compiled to the same Core code.
2014-03-01Do not emit blatantly illformed Core Erlang apply expressionsAnthony Ramine
(fun f/1)() should be compiled to let X = 'f'/1 in apply X () to let the compiler properly generate code that will fail with badarity at runtime. Reported-by: Ulf Norell
2014-02-21Merge branch 'egil/compiler/maps-get_map_elements'Björn-Egil Dahlberg
* egil/compiler/maps-get_map_elements: compiler: Strengthen Maps compile tests compiler: Remove dead warning erts: Fix erts_debug:disassemble/1 compiler: Transform list of Args to exact literal type compiler: Test Maps aliasing compiler: Use aliasing in map pair patterns compiler: Check literal order in beam_validator erts: Introduce new instructions for combined key fetches compiler: Change map instructions for fetching values
2014-02-19compiler: Use aliasing in map pair patternsBjörn-Egil Dahlberg
2014-02-17Simplify comprehension compilation in v3_coreAnthony Ramine
Given that map comprehensions and generators and maybe && generators will be added to the language in the future, v3_core:lc_tq and v3_core:bc_tq could use a rewrite to avoid a complexity explosion, where there are as many related clauses as the product of the number of types of generators and the number of types of comprehensions. The new code abstract over all generators at the same time, there is only one clause for generators per type of comprehension, and all the filter code has been put in a common function filter_tq. It should also be noted that generator inputs are now compiled before the rest of the qualifiers, reversing names of nested comprehensions.
2014-02-13Merge branch 'bjorn/lc-warnings/OTP-11626' (early part)Björn Gustavsson
* 'bjorn/lc-warnings/OTP-11626' (early part): v3_core: Annotate list comprehensions to help out dialyzer
2014-02-07Merge branch 'hsv/using_lists_droplast'Henrik Nord
* hsv/using_lists_droplast: lib/mnesia/test/ - Replace reverse(tl(reverse(L))) with lists:droplast/1 lib/ssh - Replace reverse(tl(reverse(L))) with lists:droplast/1 lib/wx - Replace reverse(tl(reverse(L))) with lists:droplast/1 Use lists:droplast/1 in orber/orber_interceptors.erl Import and use lists:droplast/1 in v3_core/v3_kernel OTP-11678 OTP-11677
2014-01-31v3_core: Annotate list comprehensions to help out dialyzerBjörn Gustavsson
2014-01-30Issue a warning when a named fun is constructed but not usedBjörn Gustavsson
2014-01-29compiler: Squash #c_map_pair_*{} to #c_map_pair{}Björn-Egil Dahlberg
Simplify compiler internals and parsing of core format.
2014-01-28compiler: Fix v3_core for map update syntaxBjörn-Egil Dahlberg
Make map update expressions safe, i.e. (foo())#{ k1 := 1 }
2014-01-28compiler: Implement support for exact Op in MapsBjörn-Egil Dahlberg
The syntax is handled upto v3_kernel where it is reduced to previous behaviour for construction and updates. Meaning, the ':=' operator is handled exactly as '=>' operator.
2014-01-28compiler: Handle literals, not just atoms, as keys in mapsBjörn-Egil Dahlberg
2014-01-28Implement support for maps in the compilerBjörn Gustavsson
To make it possible to build the entire OTP system, also define dummys for the instructions in ops.tab.
2014-01-24Import and use lists:droplast/1 in v3_core/v3_kernelHans Svensson
Also imported lists:last/1, and removed the local definition.
2014-01-17compiler: Silence false warning for unmatched return in 'after' clauseBjörn Gustavsson
Because 26940a8c0c lifted code in the 'after' clause of 'try' to a new function, Dialyzer could produce false warnings for code such as: try ... after file:close(F) end. Mark the the call to the generated function as 'compiler_generated' to silence the warning.
2013-12-12EEP 37: Funs with namesAnthony Ramine
This adds optional names to fun expressions. A named fun expression is parsed as a tuple `{named_fun,Loc,Name,Clauses}` in erl_parse. If a fun expression has a name, it must be present and be the same in every of its clauses. The function name shadows the environment of the expression shadowing the environment and it is shadowed by the environment of the clauses' arguments. An unused function name triggers a warning unless it is prefixed by _, just as every variable. Variable _ is allowed as a function name. It is not an error to put a named function in a record field default value. When transforming to Core Erlang, the named fun Fun is changed into the following expression: letrec 'Fun'/Arity = fun (Args) -> let <Fun> = 'Fun'/Arity in Case in 'Fun'/Arity where Args is the list of arguments of 'Fun'/Arity and Case the Core Erlang expression corresponding to the clauses of Fun. This transformation allows us to entirely skip any k_var to k_local transformation in the fun's clauses bodies.
2013-10-14Merge branch 'maint'Fredrik Gustafsson
2013-09-25Merge branch 'nox/lift-after/OTP-11267'Fredrik Gustafsson
* nox/lift-after/OTP-11267: Lift 'after' blocks to zeroary functions
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-07-29Merge branch 'maint'Fredrik Gustafsson
Conflicts: bootstrap/lib/compiler/ebin/v3_core.beam
2013-07-29Merge branch 'nox/fix-comp-warnings/OTP-11212' into maintFredrik Gustafsson
* nox/fix-comp-warnings/OTP-11212: Bootstrap Silence a misleading warning with some comprehensions
2013-07-29Lift 'after' blocks to zeroary functionsAnthony Ramine
If 'after' blocks are not lifted, the ids of functions in their bodies must be killed and it can make stacktraces more confusing than they should. We lift them to zeroary functions to avoid unnecessary killings and duplication of code.
2013-06-26Merge branch 'nox/illegal-bitstring-gen-pattern/OTP-11186'Fredrik Gustafsson
* nox/illegal-bitstring-gen-pattern/OTP-11186: Bootstrap added Simplify v3_core's translation of bit string generators Forbid unsized fields in patterns of binary generators
2013-06-12Update copyright yearsBjörn-Egil Dahlberg
2013-06-07Silence a misleading warning with some comprehensionsAnthony Ramine
When compiling comprehensions with generators which are foldable to 'true', a misleading warning is emitted by sys_core_fold because a clause resulting from the compilation of the comprehension to Core Erlang is not marked as generated by the compiler. An example of such a comprehension is [ true || true ].