aboutsummaryrefslogtreecommitdiffstats
path: root/lib/compiler/test/warnings_SUITE.erl
AgeCommit message (Collapse)Author
2014-08-26compiler: Update Map testsBjörn-Egil Dahlberg
2014-06-16Fix handling of latin1 characters in false ifdef branchesBjörn Gustavsson
The fallback to latin-1 encoding would not work if the invalid UTF-8 characters occurred in a skipped branch in an -ifdef/-ifndef.
2014-03-25compiler: Throw 'nomatch' on matching with bad binary keysBjörn-Egil Dahlberg
Even if a binary key is written as a literal the compiler may choose to make an expression. Emit a warning in those cases and saying the case will not match. This is a limitation in current implementation.
2014-03-25compiler: Strengthen Maps warnings testsBjörn-Egil Dahlberg
Increases coverage.
2014-03-18Don't fail compilation for modules that contain invalid UTF-8Björn Gustavsson
The default encoding for Erlang modules is now UTF-8, and the compilation would fail if a module contained byte sequences that are not valid UTF-8 sequences. In a large project with say many hundreds of Erlang modules with names of developers such as "Björn" or "Håkan" encoded in latin-1, that could mean that many hundreds of files would need to be modified just to get started testing OTP 17. As a temporary measure to ease the transition, automatically fall back to the latin-1 encoding with a warning for any module that contains invalid byte sequences and for which no encoding has been specified. The intention is to remove this workaround in OTP 18 or 19.
2014-03-10Properly handle redundant boolean clauses in sys_core_foldAnthony Ramine
Boolean case expressions with redundant clauses could make the compiler crash: case X == 0 of false -> no; false -> no; true -> yes end. Reported-by: Ulf Norell
2014-03-04Support maps in cerl_clauses:match/2Anthony Ramine
Without this, sys_core_fold could crash on non-matching clauses using maps patterns. Reported-by: Ulf Norell
2014-01-30Issue a warning when a named fun is constructed but not usedBjörn Gustavsson
2014-01-16Generalize optimizations of case statementsBjörn Gustavsson
Case expressions such as: case {Expr1,Expr} of {V1,V2} -> ... end are already optimized to not actually build the tuple. Generalize the optimization to avoid building any kind of composite term, such as: case {ok,[A,B]} of {ok,[X,Y]} -> ... end We don't expect programmers to write such code directly, but inlining can produce such code. We need to be careful about the warnings we produce. If the case expression is a literal, it is expected that no warnings should be produced for clauses that don't match. We must make sure that we continue to suppress those warnings.
2013-06-07Silence a misleading warning with some comprehensionsAnthony Ramine
When compiling comprehensions with generators which are foldable to 'true', a misleading warning is emitted by sys_core_fold because a clause resulting from the compilation of the comprehension to Core Erlang is not marked as generated by the compiler. An example of such a comprehension is [ true || true ].
2013-01-25Update copyright yearsBjörn-Egil Dahlberg
2012-10-23compiler: Run testcases in parallelBjörn Gustavsson
Run testcases in parallel will make the test suite run slightly faster. Another reason for this change is that we want more testing of parallel testcase support in common_test.
2011-04-12compiler tests: Reinstate ?MODULE macro in calls to test_lib:recompile/1Björn Gustavsson
In 3d0f4a3085f11389e5b22d10f96f0cbf08c9337f (an update to conform with common_test), in all test_lib:recompile(?MODULE) calls, ?MODULE was changed to the actual name of the module. That would cause test_lib:recompile/1 to compile the module with the incorrect compiler options in cloned modules such as record_no_opt_SUITE, causing worse coverage.
2011-03-25sys_core_fold: Eliminate incorrect warningBjörn Gustavsson
The compiler (sys_core_fold) tries to avoid constructing tuples in case expressions. The following code: c(A, B) -> case {A,B} of {ok,X} -> X; {_,_} -> error end. will be rewritten so that no tuple is built. If a clause requires a tuple to be built as in this code: c(A, B) -> case {A,B} of {ok,X} -> X; V -> V %The tuple will be built here end. the tuple will be built in the clause(s) in which it is needed. If the value returned from the case is not used as in this code: c(A, B) -> case {A,B} of V -> V %Warning: a term is constructed, but never used end, ok. there will be an incorrect warning. Basically, what happens is that the code is reduced to: c(A, B) -> {A,B}, %Warning: a term is constructed, but never used ok. and the optimizer sees that the {A,B} tuple can't possibly be used. Eliminate the warning by adding a 'compiler_generated' annotation to the tuple. Reported-by: Kostis Sagonas
2011-03-11Update copyright yearsBjörn-Egil Dahlberg
2011-02-17Rename Suite Callback to Common Test HookLukas Larsson
2011-02-17Fix formatting for compilerLukas Larsson
2011-02-17Add init_per_suite and end_per_suiteLukas Larsson
2011-02-17Add ts_install_scb to suite/0Lukas Larsson
2011-02-17Update compiler tests to conform with common_test standardLukas Larsson
2011-02-17Update all fin_per_testcase to end_per_testcase.Lukas Larsson
2010-04-27Merge branch 'bg/compiler-suppress-result-ignored' into devErlang/OTP
* bg/compiler-suppress-result-ignored: compiler tests: Eliminate "result of expression is ignored" warnings Silence warnings for expressions that are assigned to "_" OTP-8602 bg/compiler-suppress-result-ignored It is now possible to suppress the warning in code such as "list_to_integer(S), ok" by assigning the ignored value "_" like this: "_ = list_to_integer(S), ok".
2010-04-15Silence warnings for expressions that are assigned to "_"Björn Gustavsson
There is currently no zero-cost way to silence the warning "the result of the expression is ignored", which is issued for code such as: list_to_integer(S), ok Such code can be useful for assertions or input validation. Teach the compiler to silence the warning for expressions that are explicitly assigned to to the "_" variable, such as: _ = list_to_integer(S), ok Implement it by having the v3_core pass annotate calls in Core Erlang like this: let <_> = ( call 'erlang':'list_to_integer'(S) -| ['result_not_wanted'] ) in 'ok' and modifiy sys_core_fold to suppress the warning for any call having the annotation. We deliberately do not make it possible to silence the warnings for expressions like: {build,an,unnecessary,term}, ok or is_list(L), ok because we don't know of any real-world scenarios in which that would be useful.
2009-11-20The R13B03 release.OTP_R13B03Erlang/OTP