| Age | Commit message (Collapse) | Author |
|---|
|
Prior to this change, calls inside binaries were
treated as top level which would cause the `Fun(Arg)`
call inside `<<Fun(Arg)/binary>>` to return an internal
dbg_ieval tuple and ultimately error with badarg.
|
|
|
|
|
|
* maint:
debugger: Do not quote variables and button names in windows
|
|
The bug was introduced in commit 7eaaf5.
|
|
* maint:
erts, stdlib: Fix xmllint warning
Update runtime deps to depend on new stdlib functionality
|
|
~tw and new string functions are new since OTP-20 (stdlib-3.4)
|
|
* siri/string-new-api: (28 commits)
hipe (test): Do not use deprecated functions in string(3)
dialyzer (test): Do not use deprecated functions in string(3)
eunit (test): Do not use deprecated functions in string(3)
system (test): Do not use deprecated functions in string(3)
system (test): Do not use deprecated functions in string(3)
mnesia (test): Do not use deprecated functions in string(3)
Deprecate old string functions
observer: Do not use deprecated functions in string(3)
common_test: Do not use deprecated functions in string(3)
eldap: Do not use deprecated functions in string(3)
et: Do not use deprecated functions in string(3)
os_mon: Do not use deprecated functions in string(3)
debugger: Do not use deprecated functions in string(3)
runtime_tools: Do not use deprecated functions in string(3)
asn1: Do not use deprecated functions in string(3)
compiler: Do not use deprecated functions in string(3)
sasl: Do not use deprecated functions in string(3)
reltool: Do not use deprecated functions in string(3)
kernel: Do not use deprecated functions in string(3)
hipe: Do not use deprecated functions in string(3)
...
Conflicts:
lib/eunit/src/eunit_lib.erl
lib/observer/src/crashdump_viewer.erl
lib/reltool/src/reltool_target.erl
|
|
|
|
|
|
|
|
The extended parser is used by the debugger for handling pids, ports,
references, and external funs in the evaluator area and in the
bindings area.
Notice that pids, ports, references, and external funs that cannot be
created in the currently running are ignored (as before).
|
|
|
|
The evaluated string looked like "V=<<1>>", which cannot be scanned
correctly. A space after "=" fixes the bug.
|
|
|
|
|
|
* maint:
Update copyright-year
Conflicts:
lib/dialyzer/src/dialyzer.hrl
lib/dialyzer/src/dialyzer_options.erl
lib/dialyzer/test/opaque_SUITE_data/src/recrec/dialyzer.hrl
lib/dialyzer/test/opaque_SUITE_data/src/recrec/dialyzer_races.erl
lib/hipe/icode/hipe_icode.erl
lib/hipe/main/hipe.erl
lib/hipe/main/hipe.hrl.src
lib/hipe/main/hipe_main.erl
|
|
|
|
Update compiler documentation and remove superfluous erlc flags.
|
|
The filters in a list comprehension can be guard expressions or
an ordinary expressions.
If a guard expression is used as a filter, an exception will basically
mean the same as 'false':
t() ->
L = [{some_tag,42},an_atom],
[X || X <- L, element(1, X) =:= some_tag]
%% Returns [{some_tag,42}]
On the other hand, if an ordinary expression is used as a filter, there
will be an exception:
my_element(N, T) -> element(N, T).
t() ->
L = [{some_tag,42},an_atom],
[X || X <- L, my_element(1, X) =:= some_tag]
%% Causes a 'badarg' exception when element(1, an_atom) is evaluated
It has been allowed for several releases to override a BIF with
a local function. Thus, if we define a function called element/2,
it will be called instead of the BIF element/2 within the module.
We must use the "erlang:" prefix to call the BIF.
Therefore, the following code is expected to work the same way as in
our second example above:
-compile({no_auto_import,[element/2]}).
element(N, T) ->
erlang:element(N, T).
t() ->
L = [{some_tag,42},an_atom],
[X || X <- L, element(1, X) =:= some_tag].
%% Causes a 'badarg' exception when element(1, an_atom) is evaluated
But the compiler refuses to compile the code with the following
diagnostic:
call to local/imported function element/2 is illegal in guard
|
|
|
|
|
|
This speeds up the compilation of binary literals
with string values in them. For example, compiling
a file with a ~340kB binary would yield the following
times by the compiler:
Compiling "foo"
parse_module : 0.130 s 5327.6 kB
transform_module : 0.000 s 5327.6 kB
lint_module : 0.011 s 5327.8 kB
expand_module : 0.508 s 71881.2 kB
v3_core : 0.463 s 11.5 kB
Notice the increase in memory and processing time
in expand_module and v3_core. This happened because
expand_module would expand the string in binaries
into chars. For example, the binary <<"foo">>, which
is represented as
{bin, 1, [
{bin_element, 1, {string, 1, "foo"}, default, default}
]}
would be converted to
{bin, 1, [
{bin_element, 1, {char, 1, $f}, default, default},
{bin_element, 1, {char, 1, $o}, default, default},
{bin_element, 1, {char, 1, $o}, default, default}
]}
However, v3_core would then traverse all of those
characters and convert it into an actual binary, as it
is a literal value.
This patch addresses this issue by moving the expansion
of string into chars to v3_core and only if a literal
value cannot not be built. This reduces the compilation
time of the file mentioned above to the values below:
Compiling "bar"
parse_module : 0.134 s 5327.6 kB
transform_module : 0.000 s 5327.6 kB
lint_module : 0.005 s 5327.8 kB
expand_module : 0.000 s 5328.7 kB
v3_core : 0.013 s 11.2 kB
|
|
|
|
|
|
Ignore the wxSizer returns since we are not intereseted in them
but only the side effects.
|
|
|
|
|
|
|
|
|
|
|
|
* josevalim/debugger-path/OTP-13375:
Use compile source info in debugger
|
|
Prior to this commit, the debugger relied on a simple heuristic
that traverses directory from the beam file to find a source file.
The heuristic was maintained with this patch but, if it fails,
it fallbacks to the source value in the module compile info.
In order to illustrate how it works, one of the tests that
could not find its source now passes successfully (showing the
source lookup is more robust).
|
|
* maint:
xmerl: Remove 'no_return' Dialyzer warnings
xmerl: Add suppression of Dialyzer warnings
eunit: Add suppression of Dialyzer warnings
debugger: Add suppression of Dialyzer warnings
kernel: Add suppression of Dialyzer warnings
mnesia: Add suppression of Dialyzer warnings
observer: Add suppression of Dialyzer warnings
runtime_tools: Add suppression of Dialyzer warnings
stdlib: Add suppression of Dialyzer warnings
test_server: Add suppression of Dialyzer warnings
tools: Add suppression of Dialyzer warnings
Conflicts:
lib/stdlib/src/erl_lint.erl
lib/stdlib/src/otp_internal.erl
|
|
|
|
|
|
The update was motivated by commit 8ce35b2:
"Take out automatic insertion of 'undefined' from typed record fields".
|
|
The (harmless) bug was introduced in 541e87f.
|
|
* dgud/debugger/fix-case-clause/OTP-12911:
debugger: Fix broken debugger:quick/3 start
|
|
Too much code was removed in commit 560f73141af
|
|
|
|
|
|
* zhird/leoliu/dbg_wx_trace/arg-to-gui_enable_updown:
Fix argument to gui_enable_updown in dbg_wx_trace:init/6
|
|
Fix comment on new_process message in int:subscribe/0
|
|
Applications that use the new erl_anno module are depending on STDLIB 2.5.
Note that CosNotification, Megaco, SNMP, Xmerl, and Parsetools use the
erl_anno module via the Yecc parsers only (the header file in
lib/parsetools/include/yeccpre.hrl calls the erl_anno module).
HiPE does not call the erl_anno module, but uses an exported type.
We have chosen to make HiPE dependent on the erl_anno module.
|
|
Make sure that we recognize map literals at load time, as we
do for lists and tuples. Also use maps:from_list/1 to build
a new map instead of building it up from scratch inserting one
key/value pair at the time.
|
|
The pattern in the generator for a list or binary comprehension
was processed as an expression instead of as a pattern. That
happened to work because expressions and patterns were translated
in the same way.
In the future we might want to process expressions and patterns
differently.
|
|
|
|
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.
|
|
wxFileDialog:getPaths(FD) always return the empty list
on mac when using file dialog.
|
