config_full_notation and *_short_* are both tuples, but you are guarding for them beeing lists and maps via is_list/1 and is_map/1 in the heads of Quantum.Normalizer.normalize/2…
Since I do assume your tests are passing, it seems as if the definition for your option-types is wrong.
Since it just wraps Quantum.Normalizer.normalize/2 with some prefilled arguments, its just bubbling up. Fix Quantum.Normalizer.normalize/2 and this warning will vanish.
edit
Okay I realise that only one of many heads checks for a list, but that one is causing the issue. Just change the spec to allow a list of those configs as well…
@maennchen
I understand that this issue is a few months old and that ever since the code base has advanced significantly.
Nevertheless, I have this same issue in my code base myself, and after a lot of trying I was unable to locate the root issue.
In order to get more insight, I decided to git pull that commit of yours and see if I could resolve the issue.
The issue you were having at that time was simply that @fields contained more types than covered by @typep field
@fields [:name, :schedule, :task, :overlap, :run_strategy, :timezone] @typep field :: :name | :schedule | :task | :overlap | :run_strategy # :timezone is missing here
Once you add that in, dialyzer works just fine.
BTW: You should also remove | no_return. no_return means that you are dealing with a function call that will not return any value, such as an infinite recursion. By you specifying :: Job.t | no_return, dialyzer unions that to be simply: :: no_return.
Although the error may disappear(which in this case it did not), effectively your spec fails to reflect the actual nature of your code.
It is as if you would have added that as part of the ignore under: dialyzer.ignore_warnings file
@Ajwah Thanks for your explanation. I never really understood how we solved the issue until now.
When you‘re saying that we should remove the no_return, do you mean the current codebase? I thought that the no_return is currect there because we are raising exceptions.
@maennchen I was speaking about the past code base. I have not looked at master, but based on what you are saying, if you are using no_return only when raising exceptions, then I agree that such is correct usage of it.
In the past codebase, because you were desperate to resolve that error: Function has no local return, there were multiple cases where the return type was annotated as :: Job.t | no_return
Dialyzer will interpret that as a mere :: no_return, discarding any consideration for Job.t
no_return means there is no local return whatsoever, the function can only crash or loop infinitely. If the function can return a value in at least one code path, then it should not be labeled no_return.