aboutsummaryrefslogtreecommitdiffstats
path: root/lib/debugger/src
AgeCommit message (Collapse)Author
2018-03-07Do not treat binaries as top level in dbg_ievalJosé Valim
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.
2018-02-05debugger: Do not call erlang:get_stacktrace()Hans Bolinder
2018-02-05debugger: Do not try to restore stacktraceHans Bolinder
2017-12-04Merge branch 'maint'Hans Bolinder
* maint: debugger: Do not quote variables and button names in windows
2017-12-01debugger: Do not quote variables and button names in windowsHans Bolinder
The bug was introduced in commit 7eaaf5.
2017-09-20Merge branch 'maint'Dan Gudmundsson
* maint: erts, stdlib: Fix xmllint warning Update runtime deps to depend on new stdlib functionality
2017-09-19Update runtime deps to depend on new stdlib functionalityDan Gudmundsson
~tw and new string functions are new since OTP-20 (stdlib-3.4)
2017-09-15Merge branch 'siri/string-new-api'Siri Hansen
* 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
2017-09-15debugger: Do not use deprecated functions in string(3)Dan Gudmundsson
2017-09-05debugger: Improve handling of UnicodeHans Bolinder
2017-05-04Update copyright yearRaimo Niskanen
2017-04-27debugger: Improve handling of pids, ports, and refsHans Bolinder
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).
2017-04-07debugger: Show Latin-1 code correctlyHans Bolinder
2017-04-03debugger: Enable editing of bit strings in the bindings areaHans Bolinder
The evaluated string looked like "V=<<1>>", which cannot be scanned correctly. A space after "=" fixes the bug.
2017-04-03debugger: Remove a debug printoutHans Bolinder
2017-03-08debugger: Fix handling of locations and annotationsHans Bolinder
2016-12-07Merge branch 'maint'Dan Gudmundsson
* 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
2016-12-07Update copyright-yearErlang/OTP
2016-11-29warn_obsolete_guard is already defaultRichard Carlsson
Update compiler documentation and remove superfluous erlc flags.
2016-09-02Fix overridden BIFsBjörn Gustavsson
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
2016-09-01debugger: Eliminate use of sys_pre_expandBjörn Gustavsson
2016-08-25Merge branch 'maint'Peter Andersson
2016-08-04Move expansion of strings in binaries to v3_coreJosé Valim
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
2016-07-20Make sure exit in non-interpreted code doesn't crash the debuggerPeter Andersson
2016-05-24dbg_wx* - fix remaining unmached_return warningsZandra
2016-05-24dbg_wx_* - fix unmatched return warningsZandra
Ignore the wxSizer returns since we are not intereseted in them but only the side effects.
2016-05-24int - fix unmatched_return warningsZandra
2016-05-24i - fix unmatched_return warningsZandra
2016-05-24dbg_debugged - fix unmatched_return warningsZandra
2016-05-24dbg_iserver - fix unmatched_return warningsZandra
2016-03-15update copyright-yearHenrik Nord
2016-02-26Merge branch 'josevalim/debugger-path/OTP-13375'Björn Gustavsson
* josevalim/debugger-path/OTP-13375: Use compile source info in debugger
2016-02-23Use compile source info in debuggerJosé Valim
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).
2016-02-17Merge branch 'maint'Hans Bolinder
* 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
2016-02-17debugger: Add suppression of Dialyzer warningsHans Bolinder
2015-12-15debugger: Use '::' for constraintsHans Bolinder
2015-10-09Update DebuggerHans Bolinder
The update was motivated by commit 8ce35b2: "Take out automatic insertion of 'undefined' from typed record fields".
2015-09-15debugger: Fix a bug related to the use of the erl_anno moduleHans Bolinder
The (harmless) bug was introduced in 541e87f.
2015-08-26Merge branch 'dgud/debugger/fix-case-clause/OTP-12911' into maintDan Gudmundsson
* dgud/debugger/fix-case-clause/OTP-12911: debugger: Fix broken debugger:quick/3 start
2015-08-14debugger: Fix broken debugger:quick/3 startDan Gudmundsson
Too much code was removed in commit 560f73141af
2015-06-22fix errors caused by changed line numbersBruce Yinhe
2015-06-18Change license text to APLv2Bruce Yinhe
2015-06-04Merge branch 'zhird/leoliu/dbg_wx_trace/arg-to-gui_enable_updown'Zandra Hird
* zhird/leoliu/dbg_wx_trace/arg-to-gui_enable_updown: Fix argument to gui_enable_updown in dbg_wx_trace:init/6
2015-05-26Fix argument to gui_enable_updown in dbg_wx_trace:init/6Leo Liu
Fix comment on new_process message in int:subscribe/0
2015-05-25Update runtime_dependencies in application resource filesHans Bolinder
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.
2015-04-30debugger: Optimize evaluation of new map creationBjörn Gustavsson
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.
2015-04-30dbg_iload: Correct translation of generatorsBjörn Gustavsson
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.
2015-04-30debugger: Use module erl_annoHans Bolinder
2015-04-15Raise more descriptive error messages for failed map operationsBjörn Gustavsson
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.
2014-12-19debugger: Fix debugger save options on macDan Gudmundsson
wxFileDialog:getPaths(FD) always return the empty list on mac when using file dialog.