[erlang-questions] dialyzer: user-defined types just synonyms?
Thu Apr 22 17:35:56 CEST 2010
Good point about unused=untested.
Ok, but what about the other problem?
There must be warning on line 9. I get nothing with R13b4.
Tobias Lindahl wrote:
> 2010/4/22 Dmitry Belyaev <>:
>> I saw those options already but they don't do what I'd like to see.
>> I have very complex system. And I am _heavily_ refactoring it. And thought
>> dialyzer would be of great help for me.
>> Now I see many functions that long ago had (and may will have in the future)
>> wider result type than now dialyzer infers. I get many messages like those
>> (currently I grep them from output):
>> .*: The pattern .* can never match since previous clauses completely covered
>> the type .*
>> .*: The pattern .* can never match the type .*
>> .*: The variable .* can never match since previous clauses completely
>> covered the type .*
>> I don't want to change this code (it may be needed in future). I'd better
>> make result type of function wider, so dialyzer won't warn about superflous
>> (by this moment) code.
> I'm sorry that I can't help you with this.
> However, if you are refactoring your code and creating a lot of dead
> code as you do it, it might not be a bad idea to remove the dead code.
> The argument that you might need it in the future is a bit weak since
> the code will be lying around and being untested until that.
> Personally, I would have removed the code since it then becomes clear
> that whatever functionality it implements has not been needed, nor
> tested, since the refactoring.
>> Tobias Lindahl wrote:
>>> 2010/4/22 Dmitry Belyaev <>:
>>>> It would be nice if it would intersect spec parameters and check spec
>>>> contain what dialyzer infers.
>>>> So, if I have
>>>> -spec function(A) -> B.
>>>> and dialyzer finds that real type as function(C) -> D then it would check
>>>> that C contains A and B contains D and its final type would be
>>>> function(C) -> B.
>>> Dialyzer checks that there is a non-empty intersection between the
>>> spec type and the infered type. In other words if the spec is possible
>>> at all. If not, you will get a warning.
>>> You might want to have a look at the options -Wunderspecs and
>>> -Woverspecs. They give you some more information about how the specs
>>> relate to the inferred types. They are off by default since you
>>> typically get a lot of warnings from them.
More information about the erlang-questions