| Age | Commit message (Collapse) | Author |
|---|
|
An external fun could inadvertently suppress warnings for
unused variables, such as in this example:
bug() ->
BugVar = foo(),
if true ->
fun m:f/1
end.
There would be no warning that `BugVar` was unused.
The bug was introduced in ff432e262e652, which was the commit
that extended external funs to allow variables.
https://bugs.erlang.org/browse/ERL-762
|
|
Those warnings don't make sense any more since erlang:get_stacktrace/0
is now deprecated.
|
|
* 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
|
|
|
|
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 ->
.
.
.
|
|
There could be a false warning for erlang:get_stacktrace/0
being outside a try block when it was actually inside a try
block.
https://bugs.erlang.org/browse/ERL-478
|
|
The check of bad nowarn_deprecated_function tags in -compile
attributes often made it impossible to compile modules with the
warnings_as_errors option in two consecutive releases.
|
|
Unicode atoms are handled better by the Erlang code linter.
Module names are checked for character codes greater than 255. This
means that modules invoked after the linter can assume that module
names have only Latin-1 characters.
|
|
The linter emits warnings about using '_' as type variable in
parameterized types.
|
|
erlang:get_stacktrace/0 returns the stacktrace for the latest
exception. The problem is that the stacktrace is kept until the next
exception occurs. If the last exception was a 'function_clause' or a
'badarg', the arguments for the call are also kept forever. The
arguments can be terms of any size (potentially huge).
In a future release, we would like to only allow
erlang:get_stacktrace/0 from within a 'try' expression. That would
make it possible to clear the stacktrace when the 'try' expression is
exited.
The 'catch' expression has no natural end where the stacktrace could
be cleared. The stacktrace could be cleared at the end of the function
that the 'catch' occurs in, but that would cause problems in the
following scenario (from real life, but simplified):
try
...
catch _:_ ->
io:format(...),
io:format("~p\n", [erlang:get_stacktrace()])
end.
%% In io.erl.
format(Fmt, Args) ->
Res = case ... of
SomePattern ->
catch...
...;
SomeOtherPattern ->
%% Output the formatted string here
...
end,
clear_stacktrace(), %% Inserted by compiler.
Res.
The call to io:format() would always clear the stacktrace before
it could be retrieved.
That problem could be solved by tightning the scope in which the
stacktrace is kept, but the rules for how long erlang:get_stacktrace/0
would work would become complicated.
Therefore, the solution we suggest for a future major release of
OTP is that erlang:get_stacktrace/0 will return [] if it is called
outside the 'catch' part of a 'try' expression.
To help users prepare, introduce a warning when it is likely that
erlang:get_stacktrace/0 will always return an empty list, for example
in this code:
catch error(foo),
Stk = erlang:get_stacktrace()
or in this code:
try Expr
catch _:_ -> ok end,
Stk = erlang:get_stacktrace()
|
|
* zandra/stdlib/optional-callbacks/OTP-13801:
wx: make wx_object callbacks optional
stdlib: Make gen_fsm callbacks optional
stdlib: Make gen_event callbacks optional
stdlib: Make gen_server callbacks optional
|
|
|
|
The same checks are also performed by the Dialyzer.
|
|
* ingela/corrct-otp-internal:
ssl, public_key, crypto: Change deprecated to removed
|
|
|
|
In OTP 20, all Unicode characters are allowed in atoms.
However, we have decided that we will not allow non-latin1
characters in module names in OTP 20. This restriction may
be lifted in a future major release of OTP.
Enforce the restriction in erl_lint, so that it will be a
compilation error to have a module name containing non-latin1
characters. That means that tools such as debugger, xref,
dialyzer, syntax_tools, and so on, do not have to be modified
to handle non-latin1 module names.
|
|
|
|
|
|
* hasse/stdlib/check_type_constraints/OTP-14070/PR-1214:
stdilb: Check for bad type constraints in function types
|
|
The parser recognizes the 'is_subtype(V, T)' syntax for constraints,
and of course the new 'V :: T' syntax, but other variants result in an
error message. Up to now, the parser and linter have let badly formed
constraints through, and relied upon Dialyzer to emit warnings.
is_subtype/2 cannot easily be taken out from the parser. Not only
would we need find a way to emit a (linter) warning, but there also
needs to be an option for suppressing the linter warning as
compilation with +warnings_as_errors has to work. (Notice that the
abstract format representation for 'V :: T' is the same as for
'is_subtype(V, T)'.)
This correction was triggered by an email from Robert, and Kostis
created pull request 1214 to provide a fix. However, Kostis' fix
disallowed is_subtype() altogether, which breaks backward
compatibility.
As of Erlang/OTP 19.0 (ticket OTP-11879), the 'is_subtype(V, T)' is no
longer documented.
|
|
|
|
|
|
The compiler would crash in v3_codegen when trying to compile the
following code:
is_port(_) -> false.
foo(P) when port(P) -> ok.
We *could* have the compiler interpret the code as:
is_port(_) -> false.
foo(P) when erlang:is_port(P) -> ok.
But that would encourage using the obsolete form of the guard tests.
Note that the following code is illegal:
is_port(_) -> false.
foo(P) when is_port(P) -> ok.
It produces the following diagnostic:
call to local/imported function is_port/1 is illegal in guard
Therefore, we should refuse to compile the code.
|
|
In current deprecated warnings such as `crypto:rand_bytes/1 is deprecated
and will be removed in in a future release; use crypto:strong_rand_bytes/1`,
the word "in" is duplicated.
|
|
|
|
|
|
|
|
|
|
|
|
While we are it, also re-ident the files.
|
|
We want to re-ident the source files after having taken out
all ?line macros. When re-indenting using Emacs, it's important
that comments that should be at the beginning of a line (or
follow the indentation of statements around it) must start with
"%%".
|
|
|
|
There is no practial difference.
|
|
|
|
Either rely on the default 30 minutes timetrap, or set the timeout
using the supported methods in common_test.
|
|
* bjorn/remove-test_server/OTP-12705:
Remove test_server as a standalone application
Erlang mode for Emacs: Include ct.hrl instead test_server.hrl
Remove out-commented references to the test_server applications
Makefiles: Remove test_server from include path and code path
Eliminate use of test_server.hrl and test_server_line.hrl
|
|
|
|
As a first step to removing the test_server application as
as its own separate application, change the inclusion of
test_server.hrl to an inclusion of ct.hrl and remove the
inclusion of test_server_line.hrl.
|
|
The two bad record usage test cases in compile_SUITE do not
belong there, as the errors are detected in erl_lint. Move the
test to the erl_lint_SUITE.
|
|
* maint:
stdlib: Fix linter crash due to missing -module declaration
Conflicts:
lib/stdlib/test/erl_lint_SUITE.erl
|
|
The Erlang Code Linter no longer crashes if there is a -deprecated()
attribute but no -module() declaration.
See also ERL-62 at bugs.erlang.org.
|
|
The syntax -spec/callback F/A :: FunctionType; has been removed.
No deprecation was deemed necessary.
|
|
* maint:
Extend erl_lint:format_error/1 to handle bittype mismatches
erl_lint_SUITE: Add smoke test of format_error/1
|
|
erl_lint:format_error/1 would crash with a function error if
conflicting types were given. That was most easily noticed in the
shell:
Eshell V7.0.3 (abort with ^G)
1> <<0/integer-binary>>.
*** ERROR: Shell process terminated! ***
Noticed-by: Aleksei Magusev
|
|
The test suite depended on the compiler to call
erl_lint:format_error/1 to ensure that format_error/1 was
covered. Unfortunately, though, if format_error/1 crashed
the compiler would catch the exception so that the test suite
would not notice it.
Add a smoke test of format_error/1 that will crash if there is
any problem with erl_lint:format_error/1.
|
|
This type modifier was missed in 90efeaf21147505b1e8207822e606027f94183cc.
|
|
The recently added module erl_anno can no longer handle
negative line numbers.
|
|
|
|
|
|
The returned variable table when linting a map expression shouldn't include
variables that didn't appear in the expression.
Reported-By: Alexei Sholik
|
