| Age | Commit message (Collapse) | Author |
|---|
|
Messages regarding guards with orelse/andalso could look
like "Clause guard cannot succeed. The variable A was matched
against the type any()". Now they look like as if or/and is
used: "Guard test is_integer(A::atom()) can never succeed".
|
|
Messages like "The attempt to match a term of type rec_api:f()
against the variable _ breaks the opaqueness of rec_adt:f()" now
look like "The attempt to match a term of type rec_adt:f()
against the record field 'f' with type rec_api:f() breaks the
opaqueness of the term".
|
|
Warnings about clauses that cannot match and are also compiler generated
are suppressed unless none of the clauses return.
This feature is useful for non-Erlang BEAM languages (such as Elixir)
that compile to Erlang and expand certain language constructs into case
statements. In that case, as long as the language construct can succeed,
these warnings are undesired and appear spurious to users that do not
check the Erlang code that their program expands into.
Thanks to José Valim for the test (slightly modified).
|
|
|
|
|
|
Dialyzer's "dataflow" module is using information from the callgraph to
determine which functions may be called at a particular call-site. Unfortunately
this information can include functions that are certainly not among the possible
choices. We don't want to emit warnings in such cases, so a "reasonable"
compromise is to stay silent if there are many possible funs and at least one of
them can succeed.
Bug reported by Dan Gudmundsson, test shrunk down by Magnus Lång.
|
|
Optimization: A few dictionaries are maps instead of dicts.
|
|
The assumption that 'try' nodes were only used to wrap entire guards is
no longer true.
We're still swallowing warnings when the handler returns successfully.
Unfortunately, bind_guard/5 would need to be refactored to return a new
state in order to generate those warnings.
|
|
Dialyzer relies heavily on the assumption that the type of a literal
that is used as a pattern is the type of any value that can match that
pattern. For maps, that is not true, and it was causing bad analysis
results. A new help function dialyzer_utils:refold_pattern/1 identifies
maps in literal patterns, and unfolds and labels them, allowing them to
be properly analysed.
|
|
|
|
|
|
Record field types have been modified due to commit 8ce35b2:
"Take out automatic insertion of 'undefined' from typed record fields".
|
|
|
|
|
|
Reported-by: Ali Sabil
|
|
In particular fix handling of records.
|
|
The -dialyzer() attribute can be used for suppressing warnings in a
module by specifying functions or warning options. It can also be used
for requesting warnings in a module.
|
|
* maint:
dialyzer, hipe: Fix a bug concerning is_record/2,3
|
|
Also fixed some cases where Dialyzer could crash due to reaching
system limits.
|
|
* maint:
[dialyzer] Correct a doc bug introduced in 0b041238
[dialyzer] Use the option 'dialyzer' to control the compiler
[dialyzer] Fix handling of literal records
|
|
This ticket is about records in Erlang code, and when to check the
fields against the (optional) types given when defining records.
Dialyzer operates on the Erlang Core format, where there are no trace
of records. The fix implemented is a Real Hack:
Given the new option 'dialyzer' erl_expand_records marks the line
number of records in a way that is undone by v3_core, which in turn
inserts annotations that can be recognized by Dialyzer.
|
|
The pre-defined types array(), dict(), digraph(), gb_set(), gb_tree(),
queue(), set(), and tid() have been removed.
|
|
Two steps are needed to make this work:
1) Avoid generating the additional "apply_constraint" in dialyzer_typesig by
reporting every function argument as a potential external function (patch on
dialyzer_dep).
This will produce correct success typings for all functions in the test case,
but dataflow would miss the key warnings that help identify the bugs.
2) Patch dialyzer_dataflow so that it uses the "handle just external" path as a
fallback whenever there are any external calls. As a result, if we have info
about some paths, then:
a) use the old "handle known apply" code to mark these functions as used and
b) ignore the generalized result and use the one found by typesig for the
return value of the apply itself.
|
|
The types array(), dict(), digraph(), gb_set(), gb_tree(), queue(),
set(), and tid() have been deprecated. They will be removed in OTP 18.0.
Instead the types array:array(), dict:dict(), digraph:graph(),
gb_set:set(), gb_tree:tree(), queue:queue(), sets:set(), and ets:tid()
can be used. (Note: it has always been necessary to use ets:tid().)
It is allowed in OTP 17.0 to locally re-define the types array(), dict(),
and so on.
New types array:array/1, dict:dict/2, gb_sets:set/1, gb_trees:tree/2,
queue:queue/1, and sets:set/1 have been added.
|
|
* bjorn/lc-warnings/OTP-11626:
dialyzer: Silence useless warnings about list comprehensions
|
|
Dialyzer will warn if the value of list comprehension is
ignored by putting it in a sequence like this:
[SomeSideEffect(E) || E <- Es],
ok
To avoid a warning, you'll have to write:
_ = [SomeSideEffect(E) || E <- Es],
ok
Most of the time, this warning is merely annoying because it does
not point out any real errors.
Kostis Sagonas suggested that by suppressing the warning for
list comprehension that return a list of a simple type (e.g. ['ok']),
there would be no warning for code such as:
[io:format("~p\n", [E]) || E <- Es],
ok
but there would be still be a warning for:
[file:close(Fd) || Fd <- Fds],
ok
because an error condition is ignored.
|
|
|
|
|
|
|
|
|
|
It is now OK to inspect and modify the internals of opaque types within
the scope of the module.
The contracts are used for decorating types with opaqueness when it is
harmless to do so. The opaqueness is propagated by the typesig module
and also by the dataflow module.
A lot of details have been fixed or updated. In particular the modules
erl_types and erl_bif_types have been modified extensively.
The version in vsn.mk has been updated to 2.7. The reason is a
modification of #opaque{} in erl_types.
Dialyzer seems to be about five percent slower than it used to be.
|
|
Dialyzer so far only supported letrecs at the top-level
and comprehension-like letrecs (i.e. that were directly applied)
in their body.
This commit address this issue by storing in the callgraph
bound letrec labels pointing to their functions. This information
is then used by the dataflow to properly lookup recursive
definitions.
|
|
|
|
This extension allowed minimal detection of race conditions that were passing
through behaviour API calls, but had no tests in any suite and also caused a
crash in R15B02.
|
|
Dialyzer no longer outputs warnings for unused anonymous functions
("funs"). Warnings are still output for unused functions.
Funs in functions with -nowarn_unused_function attributes generated
warnings for unused functions. Unused list comprehensions also
generated warnings for unused funs.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Depending of the ordering of the functions during dataflow, a
function with an infinite loop might be identified as one that
always crashes. This is fixed now, by allowing restoration of
the infinitely-looping status.
|
|
Refactorings, code movements and reflection of mutable variables in the code.
|
|
Dialyzer was not reporting unused functions with 0 arity. This was not
a real issue, until we found out that there could be cases where this
could lead to false warnings. This was the case in "no_local_return.erl".
|
|
|
|
By keeping tracks of modified types the joining of maps ha become
significantly faster.
|
|
|
|
No warnings are emitted for funs that are non-returning when the
function that generates them has a contract that specifies that
it will return such a non-returning fun.
The actual bug, reported by Tuncer Ayaz and simplified by Maria
Christakis is included in Dialyzer's tests.
|
