aboutsummaryrefslogtreecommitdiffstats
path: root/lib/stdlib/src/ms_transform.erl
AgeCommit message (Collapse)Author
2017-06-12stdlib: Evaluate expressions in fun2ms bodiesHans Bolinder
The ms_transform module, used by ets:fun2ms/1 and dbg:fun2ms, evaluates constant arithmetic expressions. This is necessary since the Erlang compiler, which normally evaluates constant expressions, does not recognize the format generated by ms_transform.
2017-06-09stdlib: Handle Unicode atoms in ms_transformHans Bolinder
2016-10-13dbg:fun2ms: allow empty list as headPéter Gömöri
Running 'dbg:fun2ms(fun([]) -> return_trace() end' resulted in an error "dbg:fun2ms requires fun with single variable or list parameter" But the empty list is actually a list and it is a valid value as a match-spec head (matching on arity-0 functions). Although its practical use is questionable this commit eliminates a small limitation of ms_transform which is not present in the match-spec grammar.
2016-06-09stdlib: Correct types and specsHans Bolinder
2016-02-17stdlib: Update ms_transform to handle typed record fieldsHans Bolinder
2015-06-18Change license text to APLv2Bruce Yinhe
2015-04-30stdlib: Use module erl_annoHans Bolinder
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-08-20Support maps in ms_transformAnthony Ramine
2014-06-15Fix locations of shadowing warnings in ms_transformAnthony Ramine
A shadowed variable in an ms_transform match expression emits a warning located at the match expression instead of the variable.
2014-01-28erts,stdlib: Teach matchspec compiler map guardsBjörn-Egil Dahlberg
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-25Update copyright yearsBjörn-Egil Dahlberg
2013-01-25Make adjustments for UnicodeHans Bolinder
2012-01-26Remove support for is_constant/1 in ms_transformBjörn Gustavsson
2011-09-08ms_transform: Fix incorrect `variable shadowed' warningsHaitao Li
Compile below module resulting incorrect warning: $ cat tmp.erl -module(tmp). -export([tmp/1]). -include_lib("stdlib/include/ms_transform.hrl"). tmp(X) when X > 100 -> Y=X, Y; tmp(X) -> ets:fun2ms(fun(Y) -> {X, Y} end). $ erlc tmp.erl ./tmp.erl:8: Warning: variable 'Y' shadowed in ms_transform fun head The scope for a variable is its function clause. Variables bound in one function clause should not interfere with other function clauses. This patch removes incorrect passing of variable bindings from one function clause to another. Signed-off-by: Haitao Li <[email protected]>
2011-05-12Types and specifications have been modified and addedHans Bolinder
2011-03-11Update copyright yearsBjörn-Egil Dahlberg
2010-06-23Add testcases for ms_transform warning and fix scopingPatrik Nyblom
2010-06-23Add warnings for shadowed variables in ms_transform funsPatrik Nyblom
Also changed compiler to allow for warnings in parse_transforms.
2009-11-20The R13B03 release.OTP_R13B03Erlang/OTP