| Age | Commit message (Collapse) | Author |
|---|
|
|
|
The linter emits warnings about using '_' as type variable in
parameterized types.
|
|
For convenience, for instance in parse transforms, the different
functions handling erl_anno:anno() can handle {eof, Location},
and are documented to handle all form_info().
|
|
|
|
* hasse/stdlib/check_type_constraints/OTP-14070/PR-1214:
stdilb: Check for bad type constraints in function types
|
|
* maint:
stdlib: Correct signatures of functions in erl_parse
|
|
The signatures of erl_parse:anno_to_term/1 and
erl_parse:anno_from_term/1 are corrected. Using these function no
longer results in false Dialyzer warnings.
|
|
* maint:
stdlib: Allow characters in types and constant patterns
|
|
Characters ($char) can be used in constant pattern expressions. They
can also be used in types and contracts.
|
|
The parser recognizes the 'is_subtype(V, T)' syntax for constraints,
and of course the new 'V :: T' syntax, but other variants result in an
error message. Up to now, the parser and linter have let badly formed
constraints through, and relied upon Dialyzer to emit warnings.
is_subtype/2 cannot easily be taken out from the parser. Not only
would we need find a way to emit a (linter) warning, but there also
needs to be an option for suppressing the linter warning as
compilation with +warnings_as_errors has to work. (Notice that the
abstract format representation for 'V :: T' is the same as for
'is_subtype(V, T)'.)
This correction was triggered by an email from Robert, and Kostis
created pull request 1214 to provide a fix. However, Kostis' fix
disallowed is_subtype() altogether, which breaks backward
compatibility.
As of Erlang/OTP 19.0 (ticket OTP-11879), the 'is_subtype(V, T)' is no
longer documented.
|
|
|
|
* maint:
stdlib: Correct types of the abstract format
|
|
The types in erl_parse.yrl are more in harmony with the description in
The Abstract Format (in ERTS User's Guide).
|
|
The previous commits have made sys_pre_expand superfluous. Since
sys_pre_expand is undocumented and unsupported it can be removed in
a major release without prior deprecation.
Also remove code in erl_parse that handles abstract code that has
passed through sys_pre_expand.
We considered deprecating sys_pre_expand just in case, but decided
against it for the following reasons:
- Anyone brave and knowledgeable enough to use sys_pre_expand should
be able to cope with sys_pre_expand being removed.
- If we kept it, but didn't test it anywhere in OTP, it could
potentially stop working. So we would probably have to add some test
cases.
|
|
* hasse/dialyzer/improve_from_form/OTP-13547:
Update primary bootstrap
stdlib: Correct types and specs
dialyzer: Minor adjustments
dialyzer: Suppress unmatched_return for send/2
dialyzer: Improve the translation of forms to types
dialyzer: Use a cache when translating forms to types
dialyzer: Prepare erl_types:t_from_form() for a cache
dialyzer: Optimize erl_types:t_form_form()
dialyzer: Correct types
syntax_tools: Correct types
erts: Correct character repr in doc of the abstract format
stdlib: Correct types and specs
|
|
It is possible that '...' is added later (OTP 20.0), but for now we
are not sure of all details.
|
|
|
|
|
|
'...' is allowed at the end of of association types.
|
|
erl_types typesets mandatory keys with :=, and uses "..." as a shorthand
for "any() => any()". Add these to erl_parse so that all representable
types can be written in type-specs.
|
|
The expression in a bit string comprehension is limited to a
literal bit string expression. That is, the following code
is legal:
<< <<X>> || X <- List >>
but not this code:
<< foo(X) || X <- List >>
The limitation is annoying. For one thing, tools that transform
the abstract format must be careful not to produce code such as:
<< begin
%% Some instrumentation code.
<<X>>
end || X <- List >>
One reason for the limitation could be that we'll get
reduce/reduce conflicts if we try to allow an arbitrary
expression in a bit string comprehension:
binary_comprehension -> '<<' expr '||' lc_exprs '>>' :
{bc,?anno('$1'),'$2','$4'}.
Unfortunately, there does not seem to be an easy way to work
around that problem. The best we can do is to allow 'expr_max'
expressions (as in the binary syntax):
binary_comprehension -> '<<' expr_max '||' lc_exprs '>>' :
{bc,?anno('$1'),'$2','$4'}.
That will work, but functions calls must be enclosed in
parentheses:
<< (foo(X)) || X <- List >>
|
|
Calls to map_anno(), fold_anno(), and mapfold_anno() with lists of
erl_parse trees have been replaced. Those functions accept lists of
erl_parse trees, but it was not the intention when the functions were
introduced, and it is not documented.
|
|
|
|
The syntax -spec/callback F/A :: FunctionType; has been removed.
No deprecation was deemed necessary.
|
|
Background
-----------
In record fields with a type declaration but without an initializer, the
Erlang parser inserted automatically the singleton type 'undefined' to
the list of declared types, if that value was not present there.
I.e. the record declaration:
-record(rec, {f1 :: float(),
f2 = 42 :: integer(),
f3 :: some_mod:some_typ()}).
was translated by the parser to:
-record(rec, {f1 :: float() | 'undefined',
f2 = 42 :: integer(),
f3 :: some_mod:some_typ() | 'undefined'}).
The rationale for this was that creation of a "dummy" #rec{} record
should not result in a warning from dialyzer that e.g. the implicit
initialization of the #rec.f1 field violates its type declaration.
Problems
---------
This seemingly innocent action has some unforeseen consequences.
For starters, there is no way for programmers to declare that e.g. only
floats make sense for the f1 field of #rec{} records when there is no
`obvious' default initializer for this field. (This also affects tools
like PropEr that use these declarations produced by the Erlang parser to
generate random instances of records for testing purposes.)
It also means that dialyzer does not warn if e.g. an is_atom/1 test or
something more exotic like an atom_to_list/1 call is performed on the
value of the f1 field.
Similarly, there is no way to extend dialyzer to warn if it finds record
constructions where f1 is not initialized to some float.
Last but not least, it is semantically problematic when the type of the
field is an opaque type: creating a union of an opaque and a structured
type is very problematic for analysis because it fundamentally breaks
the opacity of the term at that point.
Change
-------
To solve these problems the parser will not automatically insert the
'undefined' value anymore; instead the user has the option to choose the
places where this value makes sense (for the field) and where it does
not and insert the | 'undefined' there manually.
Consequences of this change
----------------------------
This change means that dialyzer will issue a warning for all places
where records with uninitialized fields are created and those fields have
a declared type that is incompatible with 'undefined' (e.g. float()).
This warning can be suppressed easily by adding | 'undefined' to the
type of this field. This also adds documentation that the user really
intends to create records where this field is uninitialized.
|
|
The recently added module erl_anno can no longer handle
negative line numbers.
|
|
|
|
Add new functions erl_parse:type_inop_prec() and
erl_parse:type_preop_prec().
Get rid of paren_type used for parentheses in types.
|
|
|
|
Introduce erl_anno, an abstraction of the second element of tokens and
tuples in the abstract format. The convention that negative line
numbers can be used for silencing compiler warnings will no longer
work in OTP 19; instead the annotation 'generated' is to be used.
|
|
Robert has OK'ed the removal of the token ':-'.
|
|
|
|
|
|
|
|
Currently Name/Arity syntax is supported in list and tuple terms. This change makes it possible to use this syntax in map terms for consistency and convenience.
Example:
-custom(#{test1 => init/2, test2 => [val/1, val/2]}).
|
|
|
|
* fenollp/remove-erl_parse-legacy-map:
Replace local mapl/2 (Erlang < 5.0) unique call by a LC
|
|
Types are represented by quadruples {type, LINE, Name, Args},
but maps were represented by five-tuples
{type, LINE, map_field_assoc, Dom, Range}.
Note: this is *not* about the quadruples used for representing
expressions, {map_field_assoc,L,K,V}.
|
|
"... when _ :: ..." used to compile, but Dialyzer crashed.
|
|
product/_, union/_, range/2 as well as tuple/N (N > 0), map/N (N > 0),
atom/1, integer/1, binary/2, record/_, and 'fun'/_ can now be used as
type names.
|
|
The 'encoding' option of erl_parse:abstract/2 has been extended to
include 'none' and a callback function (a predicate).
The rationale is that a more general means of determining what integer
lists are to be represented as strings may help readability when
generating Erlang code given input in some other encoding than Latin-1
or UTF-8.
|
|
|
|
Name conforms to EEP.
|
|
|
|
In the current iteration of Maps we should deny *any* variables in
Map keys.
|
|
Did not handle Maps.
|
|
Example how to construct:
#{ K1 => V1, K2 => V2 }
How to update:
M#{ K1 => V1, K2 := V2 }
How to match:
#{ K1 := V1, K2 := V2 } = M
|
|
Example how to match or construct:
#{ K1 => V1, K2 => V2 }
How to update:
M#{ 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.
|
|
A bug has been fixed: when given the option {encoding,utf8} a list of
floating point numbers (in the correct interval) was mistakenly
returned as a string.
|
