| Age | Commit message (Collapse) | Author |
|---|
|
See also ERL-32 at bugs.erlang.org. Thanks to Ben Paxton.
|
|
Prior to this patch, the following code would not eval:
X = key,
(fun(#{X := value}) -> true end)(#{X => value})
That's because the key evaluation was using the new
list of bindings introduced on every anonymous fun.
Since keys only match on values defined prior to the
pattern and do not introduce any new binding, we must
use the full and original list of binding.
|
|
|
|
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.
|
|
|
|
Reported-by: José Valim
|
|
Reported-by: José Valim
|
|
|
|
* josevalim/jv-eval-guards/OTP-11747:
Fix erl_eval bug when erlang:'=='/2 is used in guards
|
|
Map fields (K := V, K => V) are not expressions and shouldn't be clauses of
erl_eval:expr/5.
|
|
Prior to this commit, erl_eval did not properly evaluate
erlang:'=='/2 and friends in guard clauses because it
always flattened it to a local call ==/2. This commit
removes the flattening logic while still normalizing old
guards style.
|
|
|
|
|
|
To ensure that 'master' compiles when we merge 'maint' to it,
regardless of which encoding is default in 'master', all source
files with non-ascii characters *must* have the encoding specified.
|
|
Tuples funs were removed in de7e01c958ff7c9e6da4034a53567a30a4ae5792,
but it was still possible to evaluate tuple funs in the shell.
|
|
Unicode related.
|
|
|
|
Tuple funs were deprecated in R15B (in commit a4029940e309518f5500).
|
|
|
|
Parameterized modules are not supported by HiPE.
|
|
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
|
|
Running Dialyzer on the test suites revealed a few type errors.
|
|
|
|
In the following code:
m(<<Sz:8,_:Sz/binary>>) ->
Sz = wrong.
the Sz variable is supposed to be bound in the function header and the
matching "Sz = wrong" should cause a badarg exception. But what
happens is that the Sz variables seems to be unbound and the matching
succeds and the m/1 function returns 'wrong'.
If the Sz variable is used directly (not matched), it will have
the expected value. Thus the following code:
m(<<Sz:8,_:Sz/binary>>) ->
Sz.
will correctly return the value of Sz that was matched out from
the binary.
Reported-by: Bernard Duggan
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<<A:0>> will always produce an empty binary, regardless of the
type of A. The bug is in the run-time system. Fix it so that a
non-numeric value for A will cause a badarg exception.
Reported-by: Zvi
|
|
|
