Age | Commit message (Collapse) | Author |
|
Records were not properly expanded in keys in patterns and in arguments in
map updates.
|
|
Update erlang lint and syntax expand for #{ K := V }
|
|
|
|
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.
|
|
|
|
|
|
|
|
Consistently use external (remote) calls to the BIFs element/2,
setelement/3, and is_record/3.
|
|
|
|
|
|
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
|
|
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.)
|
|
'cond' is an experimental feature that was never completed.
|
|
The guard test constant/1 was removed in R13B.
|
|
|