| 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".
|
|
It is possible that '...' is added later (OTP 20.0), but for now we
are not sure of all details.
|
|
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.
|
|
|
|
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.
|
|
|
|
|
|
* maps:from_list/1
* maps:get/2
* maps:is_key/2
* maps:merge/2
* maps:put/3
* maps:size/1
* maps:to_list/1
* maps:update/3
|
|
The type of a map is represented as a three-tuple {Pairs, DefaultKey,
DefaultValue}. DefaultKey and DefaultValue are types. Pairs is a list of
three-tuples {Key, mandatory | optional, Value}, where Key and Value are
types. All types Key must be singleton, or "known at compile time," as
the EEP put it. Examples:
#{integer()=>list()} {[], integer(), list()}
#{a=>char(), b=>atom()} {[{a, optional, char()},
{b, optional, atom()}],
none(), none()}
map() {[], any(), any()}
A more formal description of the representation and its invariants can
be found in erl_types.erl
Special thanks to Daniel S. McCain (@dsmccain) that co-authored a very
early version of this with me back in April 2014, although only the
singleton type logic remains from that version.
|
|
* maint:
dialyzer: Correct byte_size() and comparisons
Conflicts:
lib/hipe/cerl/erl_bif_types.erl
|
|
The argument of byte_size() is a bitstring().
The code in erl_bif_types that finds cases where comparisons always
return true or false is corrected when it comes to maps and bit
strings.
|
|
Parameterized modules are no longer supported, so module() can only be
an atom().
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* lucafavatella/dialyzer-fun-literal-arity:
Teach Dialyzer arity of funs with literal arity
OTP-13068
|
|
Background
-----------
In record fields with a type declaration but without an initializer, the
Erlang parser inserted automatically the singleton type 'undefined' to
the list of declared types, if that value was not present there.
I.e. the record declaration:
-record(rec, {f1 :: float(),
f2 = 42 :: integer(),
f3 :: some_mod:some_typ()}).
was translated by the parser to:
-record(rec, {f1 :: float() | 'undefined',
f2 = 42 :: integer(),
f3 :: some_mod:some_typ() | 'undefined'}).
The rationale for this was that creation of a "dummy" #rec{} record
should not result in a warning from dialyzer that e.g. the implicit
initialization of the #rec.f1 field violates its type declaration.
Problems
---------
This seemingly innocent action has some unforeseen consequences.
For starters, there is no way for programmers to declare that e.g. only
floats make sense for the f1 field of #rec{} records when there is no
`obvious' default initializer for this field. (This also affects tools
like PropEr that use these declarations produced by the Erlang parser to
generate random instances of records for testing purposes.)
It also means that dialyzer does not warn if e.g. an is_atom/1 test or
something more exotic like an atom_to_list/1 call is performed on the
value of the f1 field.
Similarly, there is no way to extend dialyzer to warn if it finds record
constructions where f1 is not initialized to some float.
Last but not least, it is semantically problematic when the type of the
field is an opaque type: creating a union of an opaque and a structured
type is very problematic for analysis because it fundamentally breaks
the opacity of the term at that point.
Change
-------
To solve these problems the parser will not automatically insert the
'undefined' value anymore; instead the user has the option to choose the
places where this value makes sense (for the field) and where it does
not and insert the | 'undefined' there manually.
Consequences of this change
----------------------------
This change means that dialyzer will issue a warning for all places
where records with uninitialized fields are created and those fields have
a declared type that is incompatible with 'undefined' (e.g. float()).
This warning can be suppressed easily by adding | 'undefined' to the
type of this field. This also adds documentation that the user really
intends to create records where this field is uninitialized.
|
|
Fix the range type of erlang:abs/1.
|
|
Re-insert logic for `erlang:make_fun/3` in `erl_bif_types`. It had
been removed in bd941f5 while type spec-ing `erlang.erl`. Type spec in
`erlang.erl` cannot express arity of returned fun based on value of
argument hence re-introducing logic in `erl_bif_types`.
Re-definition of logic in `erl_bif_types` follows approach in 9d870a0.
|
|
|
|
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: correct record updates
|
|
Correct a bug introduced in commit 8498a3.
|
|
* maint:
hipe: Correct pretty-printing of bitstrings
|
|
|
|
* 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.
|
|
|
|
|
|
|
|
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.
|
|
* aronisstav/hipe/opaque_fix:
Don't 'opaque-decorate' a success typing using an incompatible spec
|
|
Without this patch Dialyzer crashes when analyzing the supplemented test case.
|
|
Guard constraints used to be limited to a certain depth, which handled
mutually depending constraints safely, but also sometimes introduced
unnecessary generalizations.
This patch puts no explicit limit upon guard constraints (other than
those that already exist in erl_types), but breaks cycles by replacing
variables with the any() type.
In some cases the old method resulted in more warnings, but since the
limit was quite arbitrary and mutually depending guard constraints are
(very) rare, the new method should been seen as an improvement since
it handles cases that used to make Dialyzer loop or miss warnings.
|
|
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.
|
|
Handle immediate opaque types as aliases:
A declaration of dict/0
-opaque dict() :: dict(_, _).
-opaque dict(Key, Value) :: ...
is handled as an alias, that is, when using dict() it is immediately
replaced by dict(_, _).
This is a means to avoid having to handle equivalent opaque types
later. To be changed if it doesn't work well.
|
|
|
|
This changed the lines so the results now differ.
|
|
The function name can give information that the line number doesn't,
for example when using a parse transform that creates new functions.
|
|
|
|
|
|
The recommended type for filenames is a list of characters (which
may be Unicode characters greater than 255). Change the
file:filename() to reflect that.
For the filename module we still need a type that can be either
a string or a binary, so we need to introduce the type
file:filename_all().
|
|
|
|
* sa/dialyzer-unknown-arity-funs/OTP-10772:
Update one more unused funs result as per ffe582b
Remove pubsub and comm_layer tests from testsuite
Properly support functions with arbitrary arity in type specs.
Conflicts:
lib/hipe/cerl/erl_types.erl
|
|
|
