Dialyzer - The created fun has no local return

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…

Thanks for taking the time to look at the issue

I already tried adding | Keyword.t to the config_full_notation. This had now effect on the errors. Is this what you mean with your feedback?

Changes Made:

diff --git a/lib/quantum/normalizer.ex b/lib/quantum/normalizer.ex
index a930616..55fd35c 100644
--- a/lib/quantum/normalizer.ex
+++ b/lib/quantum/normalizer.ex
@@ -16,7 +16,8 @@ defmodule Quantum.Normalizer do
            :timezone]
 
   @type config_short_notation :: {config_schedule, config_task}
-  @type config_full_notation :: {config_name | nil, Keyword.t | map}
+  @type config_full_notation :: {config_name | nil, Keyword.t | map} | Keyword.t
+  @type config_notation :: config_short_notation | config_full_notation
 
   @typep field :: :name | :schedule | :task | :overlap | :run_strategy
   @type config_schedule :: CronExpression.t | String.t | {:cron, String.t} | {:extended, String.t}
@@ -32,7 +33,7 @@ defmodule Quantum.Normalizer do
     * `job` - The Job To Normalize
 
   """
-  @spec normalize(Job.t, config_full_notation | config_short_notation) :: Job.t | no_return
+  @spec normalize(Job.t, config_notation) :: Job.t | no_return
   def normalize(base, job)
   def normalize(%Job{} = base, job) when is_list(job) do
     normalize_options(base, job |> Enum.into(%{}), @fields)

Here you require job to be a list. Guessing from the implementation it seems to be a list of configs. That’s not covered by your spec.

If I remove this function clause entirely, I get the same error. So I’m not sure that this is the problem.

@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.