Closed fishcakez closed 10 years ago
I have fixed the ArgumentError, RuntimeError and the missing Range.t type. I will add cover to PLT and fix the underspecified module type specs. Although I think we should remove the warning that explicitly requires _ =
to be used. It is too much work just to appease the dialyzer god.
I will post more updates here.
I can find some time tomorrow to fix some of these, let me know what you resolve.
Ok, let me be specific then. I will solve:
I will do:
@fishcakez isn't this a dialyzer bug:
lib/behaviour.ex:108: The call _@1:'line'() requires that _@1 is of type atom() | tuple() not #{}
In the generated code, that clause will never be a map because we always match on maps before. It feels like they should take it into account?
I think that one is not a bug because the erlang code generated is roughly equivalent to:
% It is casing on a map not a variable so dialyzer see this is a bug, which really it is if it were erlang.
case #{line => 108} of
Map when is_map(Map) ->
'Elixir.Map':'fetch!'(Map, line);
Other ->
Other:line()
end
I am 90% confident the warnings are actually on variables. The cases it would be a literal would be on __CALLER__
but we inline those.
You picked an example where it was hard to tell from the elixir code, looking at others though dialyzer isn't inferring the case patterns can't match because we aren't getting warnings that "pattern can never match" on these case clauses. This is a bug for sure. I am unsure if I used 17.0 or 17.1, so will need to check it is present in 17.1.
I have pushed commits that:
I will update the description as soon as the results come out.
Closing this. The majority of remaining warnings can only be fixed if Elixir has a better idea of types in the system and this is something we will tackle on after 1.0. Thanks for all the contributions @fishcakez!
There are some frequent warnings:
The following warning occurs for elixir modules because a stricter spec is possible:
Similar cases often show how specs can be improved:
The following warning occurs because the default specs do not include binary arguments. This can be solved by manually adding the spec to
ArgumentError
andRuntimeError
:The following warning (or similar) occurs because a function that does not just return a singular atom does not have its return value matched on. Most of these case occurs because a function can return
:ok
or{:error, reason}
and it has not been ensured that the return value is:ok
. It is likely most of these are bugs as the assumption has been made that they return:ok
. If it is safe not to match the return value an explicit_ =
can be used to show the return value is ignored.The following warning (or similar) occurs because dialyzer is smarter than elixir's compile in inferring types. These are probably not be bugs when the variable starts with
_@
.The following warning (or similar) might be a bug but usually the function is only called from a macro. In future elixir's compiler could remove these:
The following warning occurs when a function always raises and it is not spec-ed to
no_return()
:A similar message, which might be a bug in code or specs because dialyzer believes, due to the specs, the function must raise (though it may just call a function that explicitly raises). These all need to be checked.
There are many unknown functions, these are unimplemented protocol callbacks or
:cover
because I missed it from the plt.There is one unknown type,
'Elixir.Range':t/0
, which can be resolved by defining it. It is likely this, and perhaps others, were not explicitly re-added when the default struct type declaration was removed.Here's the full list of warnings, there maybe some warnings not mentioned above that need addressing:
Updated: 3rd July 2014