aboutsummaryrefslogtreecommitdiffstats
path: root/lib/stdlib/src/erl_expand_records.erl
AgeCommit message (Collapse)Author
2014-01-28Update erl_lint, erl_expand_records, sys_pre_expand for MapsBjörn-Egil Dahlberg
Update erlang lint and syntax expand for #{ K := V }
2014-01-28Update erl_lint, erl_expand_records, sys_pre_expand for mapsBjörn Gustavsson
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-01-09erl_expand_records: Remove support for packagesBjörn Gustavsson
2012-12-03erl_expand_records: Remove stale support for literal tuple funsBjörn Gustavsson
2012-03-30Update copyright yearsBjörn-Egil Dahlberg
2012-01-25Ensure that generated record operations don't call local functionsBjörn Gustavsson
Consistently use external (remote) calls to the BIFs element/2, setelement/3, and is_record/3.
2011-09-15Fix misspelling of successfulTuncer Ayaz
2011-05-12Types and specifications have been modified and addedHans Bolinder
2010-06-07Fix confusing dialyzer warnings for is_record/2 with illegal recordsBjörn Gustavsson
In commit 1858cb81391d2bce29b4b7620574ca60128cebf7, erl_expand_records started to optimize is_record/2 in guards by replacing it with pattern matching (if possible). Unfortunately, dialyzer will no longer see the code before the optimization, so any warnings produced in code such as: case ExprNotProducingRecord#rec{} of X when is_record(X, rec, N) -> ... will refer to the optimized code and not the source code, which is confusing for the user. Introduce the no_is_record_optimization option for turning off the optimization and use it in dialyzer. Reported-by: Kostis Sagonas
2010-06-02erl_expand_records: Replace is_record() with matchingBjörn Gustavsson
The compiler currently generates better code for: f(#r1{}) -> r1; f(#r2{}) -> r2; f(#r3{}) -> r3. than for: g(X) when is_record(X, r1) -> r1; g(X) when is_record(X, r2) -> r2; g(X) when is_record(X, r3) -> r3. The compiler generates good code for pattern matching (as in f/1), but in g/1 there are no patterns to match, and the clause to be executed must be chosen by evaluating the guards sequentially until one succeeds. Make the compiler generate better code by replacing calls to is_record() with matching in the function head (basically, g/1 will automatically be rewritten to do pattern matching as in f/1). Note that this rewrite will also benefit code such as: h(X) when X#r1.a =:= 1 -> ok. because it would have been rewritten to: h(X) when (is_record(X, r1, 3) orelse fail) and (element(2, X) =:= 1) -> ok. which in turn will be rewritten to: h({r1,_,_}=X) when (true orelse fail) and (element(2, X) =:= 1) -> ok. (That will be further simplified in later compiler passes.)
2010-03-16Remove stray code supporting 'cond'Björn Gustavsson
'cond' is an experimental feature that was never completed.
2010-03-16Remove stray code supporting constant/1Björn Gustavsson
The guard test constant/1 was removed in R13B.
2009-11-20The R13B03 release.OTP_R13B03Erlang/OTP