[erlang-questions] Dyalizer warnings for too wide return type

[Alexey Romanov]

Yours, Alexey Romanov



On Fri, Oct 15, 2010 at 1:45 PM, Vincent de Phily
<vincent.dephily@REDACTED> wrote:
> On Tuesday 12 October 2010 08:48:57 Alexey Romanov wrote:
>> One problem I have with Dialyzer is that it complains about cases
>> where the return type specified is too wide.
>>
>> E.g.
>>
>> -type handle_cast_return() :: {noreply, tuple()} | {noreply, tuple(),
>> integer()} | {stop, any(), tuple()}.
>> -spec handle_cast(any(), tuple()) -> handle_cast_return().
>> handle_cast(_Msg, State) ->
>>     {noreply, State}.
>>
>> The definition says that handle_cast returns what it is supposed to
>> return according to behaviour, but it gives this warning:
> [...]
>> the given specification satisfies it, and shouldn't result in a
>> warning. Or at least, there should be an option to turn this set of
>> warnings off, and I don't see one in
>> `dialyzer -Whelp`.
>
> It sounds like -Wunderspecs or -Woverspecs would do that, but that doesn't
> seem to work.
> Actually it looks like (contrary to documentation) -Wunderspecs
> is on by default and we actually need a -Wno_underspecs option.

If I enable -Wunderspecs, I get a lot more warnings, so it isn't on by default.
These warnings don't seem to be considered underspecs for some reason.

>> In addition to the warning about some_test() I get warnings about
>> foo(): "Pattern 'true' can never match type 'false' ", any functions
>> called only from the 'true' branch are reported to be unused, etc.
>> While these warnings are correct, they ignore my specification for
>> some_test(). Can Dialyzer be forced to prefer the return type given in
>> the spec over the` one it infers?
>
> Yes, that annoys me as well. I understand the warning for the some_spec
> function, but I think it shouldn't trickle down to the foo function. I have
> another use-case where I recompile a module at runtime but provide an initial
> implementation that always returns false.
>
> I'd like dializer to trust me when I declare my interface, even if the
> implementation doesn't match that. Actually, maybe we could make the case that
> non-exported functions must have an exact spec whereas exported function can
> have a spec that is more allowing than the implementation ?

This may be reasonable.

> --
> Vincent de Phily
> Mobile Devices
> +33 (0) 142 119 325
> +353 (0) 85 710 6320
>
> Warning
> This message (and any associated files) is intended only for the use of its
> intended recipient and may contain information that is confidential, subject
> to copyright or constitutes a trade secret. If you are not the intended
> recipient you are hereby notified that any dissemination, copying or
> distribution of this message, or files associated with this message, is
> strictly prohibited. If you have received this message in error, please
> notify us immediately by replying to the message and deleting it from your
> computer. Any views or opinions presented are solely those of the author
> vincent.dephily@REDACTED and do not necessarily represent those of
> the
> company. Although the company has taken reasonable precautions to ensure no
> viruses are present in this email, the company cannot accept responsibility
> for any loss or damage arising from the use of this email or attachments.
>