aboutsummaryrefslogtreecommitdiffstats
path: root/lib/stdlib/test/erl_lint_SUITE.erl
AgeCommit message (Collapse)Author
2019-05-03stdlib: Do not allow specs for functions in other modulesHans Bolinder
See also https://bugs.erlang.org/browse/ERL-845. [Kostis:] My suggestion is that the compiler refuses to compile modules that contain specs for functions that are not from this module. I do not remember when / why this `feature' was introduced, but thinking about it I see a lot of (ugly) semantics issues with it. For example, should one be allowed to declare in the foo module that lists:flatten/1 takes an integer() as an argument and returns a binary()? Should one be allowed to declare a spec in some module m1 for a function of m2 that is not defined in m2? There are all kinds of checks that will need to be added to dialyzer to protect itself from these semantics issues. The compiler already refuses to compile modules that contain specs for non-existing functions of the module. Similarly, it should refuse to compile modules that contain specs for functions of other modules - unless it can somehow check that these functions are indeed defined, but it is not how the compiler currently works.
2019-04-09Issue an error for improper use of record_info/2 in a funBjörn Gustavsson
`record_info/2` is a pseudo-function that requires literal arguments known at compile time. Therefore, the following usage is illegal: f() -> fun record_info/2. However, `erl_lint` did not issue a compilation error for this usage, and the compiler would crash in a later pass. https://bugs.erlang.org/browse/ERL-907
2019-04-05Add options for suppressing warnings about removed functionsBjörn Gustavsson
An appliction outside of OTP may want to reuse then name of a module that was previously included in OTP. Therefore, there should be a way to suppress warnings for removed functions.
2019-04-05Don't warn for removed functions in OTP 18 or olderBjörn Gustavsson
2018-12-18Make all compiler options work in the option listBjörn Gustavsson
Before OTP 22, the option `{nowarn_deprecated_function,MFAs}` was only recognized when given in the file with the attribute `-compile()`. (The option `{nowarn_unused_function,FAs}` was incorrectly documented to only work in a file, but it also worked when given in the option list.) Starting from OTP 22, all options that can be given in the file can also be given in the option list.
2018-11-22Merge branch 'maint'Björn Gustavsson
* maint: Fix inadvertently suppressed warning for unused variable
2018-11-21Fix inadvertently suppressed warning for unused variableBjörn Gustavsson
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
2018-07-27Change "can not" into "cannot"Raimo Niskanen
I did not find any legitimate use of "can not", however skipped changing e.g RFCs archived in the source tree.
2018-04-16Remove warnings for improper use of erlang:get_stacktrace/0Björn Gustavsson
Those warnings don't make sense any more since erlang:get_stacktrace/0 is now deprecated.
2018-01-23Merge branch 'maint'Hans Bolinder
* 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
2018-01-22stdlib: Correct contractsHans Bolinder
2017-11-30Add syntax in try/catch to retrieve the stacktrace directlyBjörn Gustavsson
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 -> . . .
2017-09-06Eliminate incorrect get_stacktrace/0 warningBjörn Gustavsson
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
2017-06-22stdlib: Accept all nowarn_deprecated_function optionsHans Bolinder
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.
2017-06-09stdlib: Add more checks of module names to the linterHans Bolinder
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.
2017-05-22stdlib: Warn for bad type variables of parameterized typesHans Bolinder
The linter emits warnings about using '_' as type variable in parameterized types.
2017-05-12Warn for potentially unsafe use of get_stacktrace/0Björn Gustavsson
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()
2017-04-24Merge branch 'zandra/stdlib/optional-callbacks/OTP-13801'Zandra Norman
* 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
2017-04-21stdlib: Make gen_server callbacks optionalZandra Norman
2017-04-13stdlib: Add checks of the dialyzer attribute to the linterHans Bolinder
The same checks are also performed by the Dialyzer.
2017-03-21Merge branch 'ingela/corrct-otp-internal'Ingela Anderton Andin
* ingela/corrct-otp-internal: ssl, public_key, crypto: Change deprecated to removed
2017-03-20ssl, public_key, crypto: Change deprecated to removedIngela Anderton Andin
2017-03-16Don't allow module names with non-latin1 charactersBjörn Gustavsson
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.
2017-03-08stdlib: Fix handling of locations and annotationsHans Bolinder
2017-01-25Update test cases for erlang:hash/2 removalBjörn-Egil Dahlberg
2017-01-13Merge branch 'hasse/stdlib/check_type_constraints/OTP-14070/PR-1214'Hans Bolinder
* hasse/stdlib/check_type_constraints/OTP-14070/PR-1214: stdilb: Check for bad type constraints in function types
2016-12-01stdilb: Check for bad type constraints in function typesHans Bolinder
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.
2016-11-30stdlib test suite: fix uses of export_allRichard Carlsson
2016-11-29Make warn_export_all the defaultRichard Carlsson
2016-09-02Don't crash when obsolete guard overrides local functionBjörn Gustavsson
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.
2016-05-07Fix deprecated warningsYuki Ito
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.
2016-05-02stdlib: Strengthen map pattern testsBjörn-Egil Dahlberg
2016-05-02stdlib: Add lint tests for parallel match of mapsBjörn-Egil Dahlberg
2016-05-02stdlib: Refactor erl_lint_SUITEBjörn-Egil Dahlberg
2016-04-18stdlib: The type map() is built-inHans Bolinder
2016-03-09Eliminate use of ?config() macroBjörn Gustavsson
2016-03-09Remove ?line macrosBjörn Gustavsson
While we are it, also re-ident the files.
2016-03-09Replace "%" with "%%" at the beginning of a lineBjörn Gustavsson
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 "%%".
2016-03-09Eliminate 'suite' and 'doc' clausesBjörn Gustavsson
2016-03-09Replace use of test_server:format/2 with io:format/2Björn Gustavsson
There is no practial difference.
2016-03-09Eliminate use of test_server:fail/0,1Björn Gustavsson
2016-03-09Modernize use of timetrapsBjörn Gustavsson
Either rely on the default 30 minutes timetrap, or set the timeout using the supported methods in common_test.
2016-02-18Merge branch 'bjorn/remove-test_server/OTP-12705'Björn Gustavsson
* 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
2016-02-17stdlib: Let the linter detect old typed recordsHans Bolinder
2016-02-17Eliminate use of test_server.hrl and test_server_line.hrlBjörn Gustavsson
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.
2016-02-05Move record compilation errors to erl_lint_SUITEBjörn Gustavsson
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.
2016-01-13Merge branch 'maint'Hans Bolinder
* maint: stdlib: Fix linter crash due to missing -module declaration Conflicts: lib/stdlib/test/erl_lint_SUITE.erl
2016-01-13stdlib: Fix linter crash due to missing -module declarationHans Bolinder
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.
2015-12-15stdlib: Remove undocumented function specification syntaxHans Bolinder
The syntax -spec/callback F/A :: FunctionType; has been removed. No deprecation was deemed necessary.
2015-12-04Merge branch 'maint'Björn Gustavsson
* maint: Extend erl_lint:format_error/1 to handle bittype mismatches erl_lint_SUITE: Add smoke test of format_error/1