| Age | Commit message (Collapse) | Author |
|---|
|
|
|
According to EEP-43 for maps, a 'badmap' exception should be
generated when an attempt is made to update non-map term such as:
<<>>#{a=>42}
That was not implemented in the OTP 17.
José Valim suggested that we should take the opportunity to
improve the errors coming from map operations:
http://erlang.org/pipermail/erlang-questions/2015-February/083588.html
This commit implement better errors from map operations similar
to his suggestion.
When a map update operation (Map#{...}) or a BIF that expects a map
is given a non-map term, the exception will be:
{badmap,Term}
This kind of exception is similar to the {badfun,Term} exception
from operations that expect a fun.
When a map operation requires a key that is not present in a map,
the following exception will be raised:
{badkey,Key}
José Valim suggested that the exception should be
{badkey,Key,Map}. We decided not to do that because the map
could potentially be huge and cause problems if the error
propagated through links to other processes.
For BIFs, it could be argued that the exceptions could be simply
'badmap' and 'badkey', because the bad map and bad key can be found in
the argument list for the BIF in the stack backtrace. However, for the
map update operation (Map#{...}), the bad map or bad key will not be
included in the stack backtrace, so that information must be included
in the exception reason itself. For consistency, the BIFs should raise
the same exceptions as update operation.
If more than one key is missing, it is undefined which of
keys that will be reported in the {badkey,Key} exception.
|
|
|
|
|
|
Namely, extend the HiPE tagging scheme info, properly handle the translation
of the (is_)map type test to Icode and RTL and support handling of the map()
type in the type system.
While at it, also performed some clean up of things that needed small fixes.
|
|
|
|
|
|
|
|
|
|
The types array(), dict(), digraph(), gb_set(), gb_tree(), queue(),
set(), and tid() have been deprecated. They will be removed in OTP 18.0.
Instead the types array:array(), dict:dict(), digraph:graph(),
gb_set:set(), gb_tree:tree(), queue:queue(), sets:set(), and ets:tid()
can be used. (Note: it has always been necessary to use ets:tid().)
It is allowed in OTP 17.0 to locally re-define the types array(), dict(),
and so on.
New types array:array/1, dict:dict/2, gb_sets:set/1, gb_trees:tree/2,
queue:queue/1, and sets:set/1 have been added.
|
|
To reproduce the error:
$ echo '-module(hello).' > hello.erl
$ erl
1> c(hello, [native,{hipe,[no_remove_comments]}]).
[...]
<HiPE (v 3.10.2.1)> Error: [hipe:834]: ERROR: {{case_clause,
{icode_comment,call_ext_only}},
[{hipe_icode,successors,1,
[{file,"hipe_icode.erl"},
{line,1444}]},
[...]
|
|
|
|
|
|
|
|
* ks/hipe-cleanup-escaping/OTP-11031:
Loosen the assumptions of code that handles escaping functions
|
|
The HiPE compiler implicitly relied on the assumption that a function
will never appear as both exported and also used as function closure.
This was true because the BEAM compiler prior to R16B created module
local anonymous functions for each closure. A proposed change to the
BEAM compiler invalidates this invariant, so in order to accommodate
for this change there needs to be a change of how the set of possibly
escaping functions is computed.
While doing this, the code was simplified by taking out a boolean()
tag that indicated whether a function is a closure or exported and
also slightly cleaned up the affected modules.
|
|
|
|
|
|
|
|
|
|
The following module produced erroneous results when compiled with HiPE:
-module(a).
-export([foo/1]).
foo(X) when is_number(X) ->
is_integer(X).
Running:
1> c(a).
2> a:foo(0).
true
3> hipe:c(a).
4> a:foo(0).
false % *** WRONG ***
The problem was that the 'number' case for the `hipe_icode:type_test/1`
was going to the default case where the argument was determined as being
something other than an integer. Thanks to Sebastian Egner and Johannes
Weißl for bringing the bug into attention. Fixed on the day it was reported.
|
|
|
|
Conflicts:
lib/diameter/autoconf/vxworks/sed.general
xcomp/README.md
|
|
|
|
|
|
|
|
|
|
|
|
* maint:
Update to work with space in include path
Update to work with whitespace in exec path
|
|
OTP-10106
OTP-10107
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Compiling single functions (as opposed to whole modules) to native
code complicates code management in HiPE. It would also vastly
complicate whole-module optimizations, such as returning multiple
return values instead of tuples within a module.
As a first step, remove the external interface for the single
compilation feature. In the future, there are many things that
could be restructured and simplified.
|
|
|
|
Conflicts:
erts/aclocal.m4
erts/include/internal/ethread_header_config.h.in
|
|
Pattern matching of floats with variable size (<<F:S/float>>) did
always fail. Judging from similar code for ints, this bug is simply
a typo.
|
|
|
|
Introduce the line/1 instruction in the compiler and the BEAM
virtual machine. It will not yet be generated by the compiler and
will not actually carry any information.
|
|
|
|
* ks/hipe-icode-range-fix:
Cleanup specs
Fix bug in the simplification of inexact comparisons
Various cleanups and cosmetic changes
OTP-9101
|
|
|
|
On 31/1/2011 Paul Guyot reported a bug in the native code compilation
of inexact equality/inequality tests between floats and integers. The
relevant test was:
f(X) ->
Y = X / 2,
Y == 0.
and hipe erroneously evaluated the calls f(0) and f(0.0) to 'false'.
The culprit was in the simplification code of the Icode range analysis
which used an erroneous test (lists:any/1 instead of lists:all/1).
|
|
|
