[erlang-bugs] Dialyzer unmatched_returns generates false positives
Tue Apr 12 11:05:37 CEST 2011
Ah, I see.
How come dialyzer complains about the list comprehension and not the
lists:foreach/2 call? Is there any difference between them that warrants
the warning in one case but not the other?
As I see it, they still run my code in a sequence and I don't understand
why I would be more interested to match the return value in one case but
not the other.
Kostis Sagonas wrote:
> Adam Lindberg wrote:
>> Using the option unmatched_returns in dialyzer seems to generate false
>> positives inside list comprehensions. Consider the following code:
>> f() -> ok.
>> g() -> [f() || _E <- lists:seq(1,3)], ok.
>> It generates the following warning:
>> Expression produces a value of type ['ok'], but this value is unmatched.
>> This is okay, because we don't actually match on the return from f().
>> I would think that the following fix removes the warning, but it does
>> g() -> [ok = f() || E <- lists:seq(1,3)], ok.
>> For a list of variable length, the only alternative would be the
>> following (which dialyzer does not complain about):
>> g() -> lists:all(fun(ok) -> true end, [ok = f() || _E <-
>> lists:seq(1,3)]), ok.
>> But it doesn't have the same behavior (will generate a function clause
>> error instead of a badmatch error if something fails).
> You misunderstand both the warning and how to fix it. Dialyzer does not
> complain that the f() return is unmatched, but it complains that the
> return from the list comprehension is unmatched. Note that the warning
> does not say 'ok' but it says ['ok'] (i.e., that a list of 'ok' values
> is unmatched). And indeed it is as far as *Erlang* is concerned.
> Now, it's true that the BEAM compiler performs an optimization that does
> not construct this list, but this is not something that is reflected in
> the operational semantics of Erlang. Because dialyzer is based on Core
> Erlang and aims to be compiler independent (it's conceivable that in the
> future some other compiler may take the place of BEAM) it does not model
> its optimizations.
> Anyway, this is not a false positive. It's a bit unfortunate, but it's
> intentional. The proper way to write this in order not to get the
> dialyzer warning with unmatched return is to write the following:
> g() ->
> lists:foreach(fun(_E) -> f() end, lists:seq(1,3)),
> If you want to write it with the list comprehension, the kosher way to
> write it is:
> g() ->
> _ = [f() || E <- lists:seq(1,3)],
More information about the erlang-bugs