| Age | Commit message (Collapse) | Author |
|---|
|
Record field types have been modified due to commit 8ce35b2:
"Take out automatic insertion of 'undefined' from typed record fields".
|
|
Record field types have been modified due to commit 8ce35b2:
"Take out automatic insertion of 'undefined' from typed record fields".
|
|
The bulk of the changes concerns cleanups and code refactorings concerning
record constructions that assigned 'undefined' to record fields whose type
did not contain this value. See commit 8ce35b2.
While at it, some new type definitions were introduced and type names were
used instead of record type notation. Minor code cleaups were also done.
|
|
|
|
Record field types have been modified due to commit 8ce35b2:
"Take out automatic insertion of 'undefined' from typed record fields".
|
|
A record field type has been modified due to commit 8ce35b2:
"Take out automatic insertion of 'undefined' from typed record fields".
|
|
erlang:is_builtin(erlang, apply, 3) returns 'false'. That seems to be
an oversight in the implementation of erlang:is_builtin/3 rather than
a conscious design decision. Part of apply/3 is implemented in C (as a
special instruction), and part of it in Erlang (only used if apply/3
is used recursively). That makes apply/3 special compared to all other
BIFs.
From the viewpoint of the user, apply/3 is a built-in function,
since it cannot possibly be implemented in pure Erlang.
Noticed-by: Stavros Aronis
|
|
|
|
It actually counts the number of subsystem alive. Allocating a channel does not consume any resources
(except some cpu cycles), but the subsystem start spawns processes.
|
|
|
|
|
|
|
|
|
|
|
|
Added encode/decode for ecdsa public keys in openssh and rfc4716
format. This is for the ssh public key algorithm ecdsa-sha2-*.
|
|
|
|
The field 'dynamics' in #state{} is a union of two opaque types, which
is possibly problematic. Tagging the types should make the code safe
for warnings from future versions of Dialyzer.
|
|
Record field types have been modified due to commit 8ce35b2:
"Take out automatic insertion of 'undefined' from typed record fields".
|
|
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.
|
|
|
|
OTP-12032
* tomszilagyi/shell-support-del-home-end:
Erlang shell: Support keys Del, Home and End
|
|
|
|
* bjorn/compiler/fix-crash:
beam_reorder: Eliminate compiler crash
|
|
* maint:
Avoid always updating inet_dns in the primary bootstrap
|
|
* bjorn/kernel/inet_dns/OTP-13027:
Avoid always updating inet_dns in the primary bootstrap
|
|
|
|
OTP-13031
* tuncer/leex-leo-liu-result-field-order:
yecc: fix file/2 error tuple doc
leex: fix file/2 error tuple doc (Reported-by: Leo Liu)
|
|
|
|
|
|
|
|
|
|
* sverk/erts/doc-review:
erts: Spell-check erlang.xml
erts: Review newer additions to erlang.xml
erts: Review module erlang docs
erts: Update module erlang docs
erts: Review time correction docs
erts: Update erts time correction docs
|
|
|
|
|
|
|
|
|
|
|
|
Conflicts:
OTP_VERSION
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The include file inet_dns_record_adts.hrl is generated by the
Perl script inet_dns_record_adts.pl in a non-deterministic way.
That is, every time the script is run, the functions will be in
a different order. That will cause inet_dns.beam in the primary
bootstrap to be updated every time the bootstrap is updated,
even though there is no actual code change.
Modify the Perl script to sort the keys pulled out from hashes
to make the order deterministic.
|
|
c288ab87 added beam_reorder to move get_tuple_element instructions.
Compiling code such as the following would crash the compiler:
alloc(_U1, _U2, R) ->
V = R#alloc.version,
Res = id(V),
_ = id(0),
Res.
The crash would occur because the following two instructions:
{get_tuple_element,{x,2},1,{x,1}}.
{allocate_zero,1,2}.
were swapped and rewritten to:
{allocate_zero,1,1}.
{get_tuple_element,{x,2},1,{x,1}}.
That transformation is not safe because the allocate_zero instruction
would kill {x,2}, which is the register that is holding the reference
to the tuple. Only do the transformation when the tuple reference is
in an x register with a lower number than the destination register.
|
|
|
|
|
|
|
|
* dgud/mnesia/restore-leak/OTP-13025:
mnesia: Fix mnesia:restore/2 which caused a disk_log leak
|
