Applied dialyzer fixes - Githubissues

smeevil commented 7 years ago

Hi there,

I had some Dialyzer errors in my project coming from Maxwell, so I thought to give it a look.

I changed the type specs of conn.ex for Atom.t, Map.t, and Stream.t, which do not exist, to their original types.
Added type spec for error.ex.
Commented out unreachable code in adapter.ex, which according to Dialyzer will never be triggered. I've been tracing the calls and I can confirm this is indeed not possible since all paths that lead to this are indeed already covered. Please double check this as well, and then remove :)

There is just one error left which is :

lib/maxwell.ex:1: The pattern _@2 = {'error', _} can never match the type {'error',_,#{'__struct__':='Elixir.Maxwell.Conn', 'method':=atom(), 'opts':=[{_,_}], 'path':=binary(), 'private':=map(), 'query_string':=map(), 'req_body':=_, 'req_headers':=#{binary()=>binary()}, 'resp_body':=binary() | maybe_improper_list(binary() | maybe_improper_list(any(),binary() | []) | byte(),binary() | []) | map(), 'resp_headers':=#{binary()=>binary()}, 'state':='error', 'status':='nil' | non_neg_integer(), 'url':=binary()}} | #{'__struct__':='Elixir.Maxwell.Conn', 'method':=atom(), 'opts':=[{atom(),_}], 'path':=binary(), 'private':=map(), 'query_string':=map(), 'req_body':='nil', 'req_headers':=#{binary()=>binary()}, 'resp_body':=binary() | maybe_improper_list(binary() | maybe_improper_list(any(),binary() | []) | byte(),binary() | []) | map(), 'resp_headers':=#{binary()=>binary()}, 'state':='sent', 'status':=non_neg_integer(), 'url':=binary()}

This is coming from the macro in builder.ex. As it is a macro it's really hard for me to track down the origins of the error. Basically what it is saying is that in the code an {:error, :message} is being thrown, while that should be {:error, :message, %Maxwell.Conn{}} , I could not find exactly where this happens so maybe you can have a look at that ?

Thanks for your time :) Gerard

coveralls commented 7 years ago

Coverage decreased (-0.005%) to 98.545% when pulling d8db2f9ce3d23e856af778b5f7bedbd0fcb4d6a4 on smeevil:master into 43e61904b6833011aa79a3801b0709cc9dd3730d on zhongwencool:master.

coveralls commented 7 years ago

Coverage remained the same at 98.551% when pulling 550b8486911de1dbdf26b3811d8885b6199e5499 on smeevil:master into 43e61904b6833011aa79a3801b0709cc9dd3730d on zhongwencool:master.

coveralls commented 7 years ago

Coverage remained the same at 98.551% when pulling 13905bff6f86a9178ef8625d7da5575346ba1f45 on smeevil:master into 43e61904b6833011aa79a3801b0709cc9dd3730d on zhongwencool:master.

coveralls commented 7 years ago

Coverage remained the same at 98.551% when pulling 13905bff6f86a9178ef8625d7da5575346ba1f45 on smeevil:master into 43e61904b6833011aa79a3801b0709cc9dd3730d on zhongwencool:master.

smeevil commented 7 years ago

Hi,

I was wondering if there is anything left that is preventing the merge for this request ?

Gerard.