dimitarvp
Property generators make Dialyzer complain, ideas how to make it happy?
Hello all,
I got a lot of functions like these in a hobby project of mine:
@spec optional_alphanum(pos_integer) :: %StreamData{}
def optional_alphanum(size) when size > 0 do
gen all str <- string([?A..?Z, ?0..?9], min_length: 0, max_length: size) do
String.pad_trailing(str, size, " ")
end
end
To which Dialyzer (through dialyxir) always complains: Function optional_alphanum/1 has no local return. I also tried appending | no_return() to the return type, and it did not help.
Any clues? I am aware that ExUnitProperties.gen is a macro but cannot decipher what I have to do to make Dialyzer happy in this case.
Most Liked
whatyouhide
If you use stateful testing there’s definitely no alternative, so nothing to say there ![]()
I’ll look into what it would take to get those into stream_data ![]()
adkron
If you don’t like opinions that say to change your libraries you can skip now.
Take a look into using PropCheck for the generators instead of StreamData. They have more control and are better at shrinking. It might also solve your dialyzer issue.
yurko
A bit offtopic but it happens from time to time that dialyzer catches problems that are external to my application (like wrong specs in a dependency), in these cases there is a way to silence specific warnings (s. dialyzer — dialyzer v5.4 ).
As a temporary measure you can add something like that to your module so that this function does not trigger warnings:
@dialyzer {:nowarn_function, optional_alphanum: 1}
dimitarvp
Fair point. But since this is a personal project, I won’t insist on 100% @spec coverage or put Dialyzer as a pre-commit hook. For the time being it’s fine if my generators aren’t specced in a way that Dialyzer likes.
adkron
That would be great to see. I always like to see multiple tools with multiple approaches. I think they help us, as a community, to learn and grow.







