Age | Commit message (Collapse) | Author |
|
* hasse/syntax_tools/fix_revert/OTP-15294:
erts: Add comment about [] and nil() to The Abstract Format
syntax_tools: Correct erl_syntax:revert/1
|
|
revert/1 did not handle the types tuple() and map() correctly.
|
|
The bug was introduced in 9ab233.
See also https://bugs.erlang.org/browse/ERL-719.
|
|
Add support of non-whole-byte binaries to `abtract/1`, `concrete/1` and
`is_literal/1`. (They are literals in the beam file)
|
|
|
|
A quick fix to make the test suite work with the updated erl_eval.
[I think that if "A:B:_" is allowed, it should have a representation
in the abstract format, but that's another story. The pretty printer
should not modify the source code, just print it nicely, IMHO. (But
removing parentheses is OK)]
|
|
|
|
|
|
This makes it clear that Apache 2.0 applies, without dropping the old LGPL
licensing, and makes all the Syntax Tools file headers look the same as
upstream.
|
|
|
|
The pretty-printing of `...' in map types is complex. The
representation of `...' can be changed before OTP 19.
|
|
|
|
In particular, types and specs can be pretty-printed.
There are issues with macros (left behind by epp_dodger).
Typed record fields are handled. Fields are represented by triples
instead of two-tuples, which is an incompatible change.
Some attributes (-export_type, -spec, -type, &c) have been given
meaning in recent time, but the set of wild attributes (see Barklund's
spec) is not changed.
|
|
|
|
|
|
(The support in erl_parse got removed when 'packages' were removed, since
the dot notation was overlaid on the existing mnemosyne access syntax.)
|
|
|
|
Affected functions:
* erl_syntax:abstract/1
* erl_syntax:concrete/1
* erl_syntax:is_leaf/1
* erl_syntax:is_literal/1
|
|
|
|
|
|
There was a copy-paste bug in erl_syntax when running
e.g. erl_syntax:revert_forms, affecting maps. Instead of getting
Key/Value you got Key/Key in the resulting abstract form.
|
|
Note: `arity_qualifier` nodes are recognized. This is to follow The
Erlang Parser when it comes to wild attributes: both {F, A} and F/A
are recognized, which makes it possible to turn wild attributes into
recognized attributes without at the same time making it impossible to
compile files using the new syntax with the old version of the Erlang
Compiler.
|
|
|
|
|
|
|
|
map_expr/1
map_expr/2
map_expr_argument/1
map_expr_fields/1
map_field_assoc/2
map_field_assoc_name/1
map_field_assoc_value/1
map_field_exact/2
map_field_exact_name/1
map_field_exact_value/1
|
|
A named fun's name is a variable name, its type in syntax_tools is named_fun_expr.
|
|
|
|
|
|
|
|
This partially reverts 290dc2b08a2f92157ac5358fba815f4dbb32f8f2 in which
implicit funs were mistakenly thought to be using abstract terms for their name
and arity.
|
|
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.
|
|
Implicit funs parts in plain AST are no longer in concrete form since
Erlang/OTP R15.
|
|
The code related to the introduction of unicode_string() and
unicode_char() has been removed. The types char() and string() have
been extended to include Unicode characters.
In fact char() was changed some time ago; this commit is about
cleaning up the documentation and introduce better names for some
functions.
|
|
|
|
|
|
Not complete.
Unicode in wild attribute doesn't work.
No support for Unicode regarding Igor stubs.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* Just remove the warnings, not fixing the actual problem.
|
|
|
|
This reverts commit 38ee7a20cfdc22ead35b4711a086babcf6b3069b.
|
|
|
|
Currently, the external fun syntax "fun M:F/A" only supports
literals. That is, "fun lists:reverse/1" is allowed but not
"fun M:F/A".
In many real-life situations, some or all of M, F, A are
not known until run-time, and one is forced to either use
the undocumented erlang:make_fun/3 BIF or to use a
"tuple fun" (which is deprecated).
EEP-23 suggests that the parser (erl_parse) should immediately
transform "fun M:F/A" to "erlang:make_fun(M, F, A)". We have
not followed that approach in this implementation, because we
want the abstract code to mirror the source code as closely
as possible, and we also consider erlang:make_fun/3 to
be an implementation detail that we might want to remove in
the future.
Instead, we will change the abstract format for "fun M:F/A" (in a way
that is not backwards compatible), and while we are at it, we will
move the translation from "fun M:F/A" to "erlang:make_fun(M, F, A)"
from sys_pre_expand down to the v3_core pass. We will also update
the debugger and xref to use the new format.
We did consider making the abstract format backward compatible if
no variables were used in the fun, but decided against it. Keeping
it backward compatible would mean that there would be different
abstract formats for the no-variable and variable case, and tools
would have to handle both formats, probably forever.
Reference: http://www.erlang.org/eeps/eep-0023.html
|
|
The declaration of the stubDescriptop() type in 'igor' was erroneous,
both in the -type and in the published documentation of the module.
While fixing this some specs where strengthened and used a remote
type to refer to ordsets:ordset(T). Consequently, this patch depends
on the ordsets module exporting the ordset/1 type.
|