| Age | Commit message (Collapse) | Author |
|---|
|
* hasse/dialyzer/extra-range/OTP-14970:
ssl: Correct some specs
os_mon: Correct a spec
Fix broken spec in beam_asm
Dialyzer should not throw away spec information because of overspec
|
|
dialyzer: Compute MD5s using the .beam file (OTP-14937)
|
|
* maint:
dialyzer: Correct a parameterized opaque types bug
|
|
The previous mechanism was based on the core file which
meant that for every module in the PLT, we had to fetch
its .beam file, retrieve Erlang AST, compile that down
to core, serialize it into a binary and then get its MD5.
In a project with stdlib, kernel, elixir and a small
application in the PLT, relying only on the .beam sped
up --check_plt from 10s to 0.8s.
|
|
See also https://bugs.erlang.org/browse/ERL-565.
To avoid loops, erl_types:t_is_subtype checks for equality using
unopaqued types, but in (at least) one case something is lost:
This fix makes sure that when forwarding arguments in dataflow, types
with different parameters but equal when unopaqued are considered
different.
For example, dict:dict(0, {}) and dict:dict(0, []) are equal when
unopaqued (due to how dict(_, _) is declared in module dict), but
should be considered different when forwarding args.
|
|
|
|
* maint:
dialyzer: Fix a crash
|
|
|
|
* hasse/no_get_stacktrace/OTP-14861:
erts: Update abstract format doc with stacktrace variable
wx: Do not call erlang:get_stacktrace()
tools: Do not call erlang:get_stacktrace()
stdlib: Do not call erlang:get_stacktrace()
sasl: Do not call erlang:get_stacktrace()
runtime_tools: Do not call erlang:get_stacktrace()
reltool: Do not call erlang:get_stacktrace()
parsetools: Do not call erlang:get_stacktrace()
observer: Do not call erlang:get_stacktrace()
mnesia: Do not call erlang:get_stacktrace() (cont)
mnesia: Do not call erlang:get_stacktrace()
kernel: Do not call erlang:get_stacktrace()
inets: Do not call erlang:get_stacktrace()
eunit: Do not call erlang:get_stacktrace()
et: Do not call erlang:get_stacktrace()
dialyzer: Do not call erlang:get_stacktrace()
debugger: Do not call erlang:get_stacktrace()
debugger: Do not try to restore stacktrace
common_test: Do not call erlang:get_stacktrace()
|
|
|
|
|
|
* maint:
kernel: Correct contracts and a bug in group_history
stdlib: Correct contracts
dialyzer: Optimize handling of a lot of warnings
Conflicts:
lib/kernel/src/erl_boot_server.erl
|
|
If the number of warnings is huge the '--'/2 operator is slow.
|
|
* maint:
dialyzer: Fix bsl/2 bug
|
|
Also modified erl_bif_types:infinity_bsl() when called with zero as
first argument. As of writing this, erlang:'bsl'/2 is modified on the
master branch to never fail if called with a huge second argument.
|
|
* maint:
dialyzer: Add a test of erl_tar:table/1,2
Fix false Dialyzer warnings for erl_tar:table/1
|
|
|
|
* maint:
dialyzer: Correct handling of erlang:abs/1
|
|
See also https://bugs.erlang.org/browse/ERL-551.
|
|
|
|
|
|
|
|
This commit adds a new syntax for retrieving the stacktrace
without calling erlang:get_stacktrace/0. That allow us to
deprecate erlang:get_stacktrace/0 and ultimately remove it.
The problem with erlang:get_stacktrace/0 is that it can keep huge
terms in a process for an indefinite time after an exception. The
stacktrace can be huge after a 'function_clause' exception or a failed
call to a BIF or operator, because the arguments for the call will be
included in the stacktrace. For example:
1> catch abs(lists:seq(1, 1000)).
{'EXIT',{badarg,[{erlang,abs,
[[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20|...]],
[]},
{erl_eval,do_apply,6,[{file,"erl_eval.erl"},{line,674}]},
{erl_eval,expr,5,[{file,"erl_eval.erl"},{line,431}]},
{shell,exprs,7,[{file,"shell.erl"},{line,687}]},
{shell,eval_exprs,7,[{file,"shell.erl"},{line,642}]},
{shell,eval_loop,3,[{file,"shell.erl"},{line,627}]}]}}
2> erlang:get_stacktrace().
[{erlang,abs,
[[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,
23,24|...]],
[]},
{erl_eval,do_apply,6,[{file,"erl_eval.erl"},{line,674}]},
{erl_eval,expr,5,[{file,"erl_eval.erl"},{line,431}]},
{shell,exprs,7,[{file,"shell.erl"},{line,687}]},
{shell,eval_exprs,7,[{file,"shell.erl"},{line,642}]},
{shell,eval_loop,3,[{file,"shell.erl"},{line,627}]}]
3>
We can extend the syntax for clauses in try/catch to optionally bind
the stacktrace to a variable.
Here is an example using the current syntax:
try
Expr
catch C:E ->
Stk = erlang:get_stacktrace(),
.
.
.
In the new syntax, it would look like:
try
Expr
catch
C:E:Stk ->
.
.
.
Only a variable (not a pattern) is allowed in the stacktrace position,
to discourage matching of the stacktrace. (Matching would also be
expensive, because the raw format of the stacktrace would have to be
converted to the cooked form before matching.)
Note that:
try
Expr
catch E ->
.
.
.
is a shorthand for:
try
Expr
catch throw:E ->
.
.
.
If the stacktrace is to be retrieved for a throw, the 'throw:'
prefix must be explicitly included:
try
Expr
catch throw:E:Stk ->
.
.
.
|
|
* maint:
dialyzer: Extend the map implementation's handling of ?unit
dialyzer: Use string:find() instead of string:str()
|
|
The Maps implementation handles ?unit in more cases.
Exactly when t_is_none_or_unit() is to be called is not clear to me.
The added cases are about a map type being ?unit, but the key or the
value of an association can also be ?unit, but that is not always
checked.
|
|
|
|
* lukas/stdlib/maps_iterators/OTP-14012:
erts: Limit size of first iterator for hashmaps
Update primary bootstrap
Update preloaded modules
erts: Remove erts_internal:maps_to_list/2
stdlib: Make io_lib and io_lib_pretty use maps iterator
erts: Implement batching maps:iterator
erts: Implement maps path iterator
erts: Implement map iterator using a stack
stdlib: Introduce maps iterator API
Conflicts:
bootstrap/lib/stdlib/ebin/io_lib.beam
bootstrap/lib/stdlib/ebin/io_lib_pretty.beam
erts/emulator/beam/bif.tab
erts/preloaded/ebin/erlang.beam
erts/preloaded/ebin/erts_internal.beam
erts/preloaded/ebin/zlib.beam
|
|
* maint:
dialyzer: Display error messages without call stack
|
|
As of commit 12b379 many of the reasons displayed after
"Analysis failed with error:"
erroneously include a call stack. The bug is now corrected.
The bug was pointed out in
http://erlang.org/pipermail/erlang-questions/2017-October/093838.html.
|
|
|
|
|
|
* lars/doc-cleanup/OTP-14475:
[edoc] Remove unused module otpsgml_layout.erl
Remove unused files from the documentation build
|
|
|
|
|
|
|
|
|
|
* 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)
|
|
* maint:
dialyzer: Adjust a test case
dialyzer: Modify handling of singleton map key types
Dialyzer: Rewrite one map type invariant
Dialyzer: Rewrite some of the docs of map types
|
|
* hasse/dialyzer/map_fixes/OTP-14572:
dialyzer: Adjust a test case
dialyzer: Modify handling of singleton map key types
Dialyzer: Rewrite one map type invariant
Dialyzer: Rewrite some of the docs of map types
|
|
* 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
|
|
|
|
* maint:
dialyzer: Improve check of unknown types
|
|
The implementation of OTP-14218 (commit 6d3b38a) has a weakness: only
a very limited part of the type form is checked. This is now fixed:
types not used by specs are checked equally well as types used by
specs.
The new function erl_types:t_from_form_check_remote() checks usage of
remote types. It does not expand used local types, and has (almost) no
limits on depth and size.
|
|
* maint:
dialyzer: Do not fix ETS tables when merging PLTs
|
|
This commit removes the call to ets:safe_fixtable/2 introduced in
commit 9458495. ETS memory can now be reclaimed while merging PLTs.
|
|
Huge maps are truncated differently by the pretty printer. The reason
is that erl_types:is_singleton_type/1 no longer recognizes complex
singleton types, which results in a less precise representation of map
types.
|
|
The test case loop.erl shows that there is a problem with certain
singleton key types. Here the internal representation toggles between
#{a | b => ...} and #{a => ..., b => ...}
The choice is to turn #{a | b => ...} into #{a => ..., b => ...} early
(t_from_form()). The aim is to keep as much info as possible (in
pairs). However, including complex singleton keys (tuples, maps) in
this scheme is potentially too costly, and a bit complicated. So one
more choice is made: let atoms and number (and nothing else) be
singleton types, and let complex keys go into the default key.
|
|
|
|
Add {continue, Term} and handle_continue/2 to gen_server
|
