tino415
Dialyzer cachex unable to solve types
Hello all,
I’m triing to integrate dialyzer/dialyxer into one project that is using cachex, but dialyzer keeps reporting some veird error with Cachex.start_link/2 function. I managed to destille minimal example:
defmodule Test do
def hello do
{:ok, _pid} = Cachex.start_link(__MODULE__, stats: true)
end
end
Dialyzer is complaining that
lib/test.ex:3:pattern_match
The pattern can never match the type.
Pattern:
{:ok, __pid}
Type:
:error | :ok | {:error, atom() | {:already_started, pid() | {_, _}}}
But when I tri to run function in iex, it returns {:ok, pid()}, also when I look at the code, typescpecs seems right and code also, so, how did dialyzer come up with return type :error | :ok | {:error, atom() | {:already_started, pid() | {_, _}}}? The code for Cachex.start_link/2 looks like this:
@spec start_link(atom | Keyword.t) :: { atom, pid }
def start_link(options) when is_list(options) do
with { :ok, name } <- Keyword.fetch(options, :name),
{ :ok, true } <- ensure_started(),
{ :ok, true } <- ensure_unused(name),
{ :ok, cache } <- setup_env(name, options),
{ :ok, pid } = Supervisor.start_link(__MODULE__, cache, [ name: name ]),
{ :ok, link } = Informant.link(cache),
^link <- Overseer.update(name, link),
do: { :ok, pid }
end
def start_link(name) when not is_atom(name),
do: error(:invalid_name)
def start_link(name),
do: start_link(name: name)
@doc false
@spec start_link(atom(), Keyword.t) :: { atom(), pid() }
def start_link(name, options),
do: start_link([name: name] ++ options)
Anybody have experience with similar problem and how to solve it?
Marked As Solved
michallepicki
This seems to be a bug in specs in the sleeplocks library and should be fixed by Fix execute/2 spec by michallepicki · Pull Request #5 · whitfin/sleeplocks · GitHub
Last Post!
michallepicki
It’s possible that Cachex also has wrong specs, at least I think in many modules types referenced from specs won’t be found by Dialyzer, e.g. here: cachex/lib/cachex/services/overseer.ex at main · whitfin/cachex · GitHub Spec is used but Supervisor.Spec is aliased, not Cachex.Spec. But I may be wrong, and in that case Dialyzer is probably smart enough to ignore the spec.
Overall this is a common problem through the Elixir ecosystem, almost none of the libraries are running Dialyzer on the CI so specs just get outdated or invalid. I try to maintain Elixir itself working somehow with Dialyzer by running a check on it every day: GitHub - michallepicki/elixir-lang-dialyzer-runs: Daily Dialyzer checks on Elixir source code · GitHub but it won’t catch some issues because they may pop up when a function is called, not defined, and I am not analyzing Elixir test modules since they are .exs files.
Trending in Questions
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #elixirconf-us
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex









