Dialyzer listed not implemented protocols as `Unknown functions`

I use protocols in my project. When I run mix dialyzer, it returns list of not implemented protocols in Unknown functions: section.


does anybody know how to fix it?


Do you have your protocol implemented for Atom type?
If not and you don’t want to implement it you can try set @fallback_to_any and in the implementation for Any then return nil.
See this link for details of the protocols and implementation for Any.
If I understand it correctly this tool checks: “what will happen if someone run a protocol method with …”.
If you do not want to implement fallback you need to find a configuration/flag/option to disable missing protocol implementations.
Here you have specified how to use flags, but I don’t know if there is any to disable this warning.

1 Like

Thank you for your replay,

I implement protocol for Any and add @fallback_to_any true to protocol, but dialyzer continuous to return this warnings.

defprotocol Paycode do
  @dialyzer {:nowarn_function, __protocol__: 1}
  @spec to_string(any) :: String.t | :error
  @fallback_to_any true
  def to_string(value)

defimpl Paycode, for: Any do
  def to_string(_value), do: :error

Did I do something wrong?

Hmm, I read some about this tool. It’s not a problem with @fallback_to_any.

On stackoverflow this line putted in protocol definition solved the problem

@dialyzer {:nowarn_function, __protocol__: 1}

but it’s not working for me.


Erlang/OTP 19 [erts-8.1] [source] [64-bit] [smp:4:4] [async-threads:10]

Elixir 1.3.4

Steps to reproduce:

  1. Install latest stable Elixir with it’s dependencies
  2. Create new project using: mix new command.
  3. Add: {:dialyxir, "~> 0.3.5", only: [:dev]} to your example app dependencies list.
  4. Run: mix deps.get and: mix deps.compile
  5. Add code from already solved stackoverflow thread.
  6. Prepare dialyzer, by executing: mix dialyzer.plt
  7. Run dialyzer: mix dialyzer

Expected behaviour:
Dialyzer should not produce any warning messages.

Actual behaviour:
Dialyzer returned many warning (unknown functions) for Elixir protocol implementations: Atom, BitString, Float, Function, List, Map, PID, Port, Reference and Tuple.

What do you think about it @jeremyjh?

1 Like

Hi, I don’t know that there is a way to suppress the unknown warnings. I think in that stack overflow thread they were suggesting the :nowarn_function attribute to deal with the warning about the inferred type/vs specification.

The unknown function warnings do not change the exit status, they are more of a warning that the analysis is incomplete. But yes they are ugly. Unfortunately this is the state of dialyzer in Elixir presently.

Right now dialyxir does not do anything to alter the output of dialyzer, its just shelling out to the dialyzer and dumping the results. I think some suppression would be a good feature here, I can definitely add this to my list.

How it was resolved on stackoverflow?
I was think that it was possible to solve for example in previous version of dialyxir …
I think this feature should be configurable in 4 ways:

  1. by ‘config exs‘ to enable/disable this by default
  2. by ‘@fallback_to_any true‘
  3. by ‘@dialyxir {skip_impl_check: true}‘
  4. by ‘@dialyxir {expected_impl: []}‘

On stack overflow there were two different problems and the solution resolved only the “first” problem. The unknown functions in the second warning are on __impl__ , not on protocol.

I can’t add any new attribute support to dialyzer; dialyxir isn’t inspecting BEAM files it just manages the PLT for you and executes the Erlang Dialyzer. But since I get the shell output and in this case there is no change in exit status, I could “erase” the unwanted messages that have to do with unknown impl and yes it would be configurable to enable/disable.

My dyalizer output is run through sed to remove things I don’t want to see that upstream libraries have borked, definitely ugly. ^.^


Oh sorry, I thought that the solution applies to both problems.

So how @dialyzer {:nowarn_function, __protocol__: 1} could work?

Exit status may be important. For example in bash: command_a && command_b.

I use protocols in my project. When I run mix dialyzer, it returns list of not implemented protocols in Unknown functions: section.

FYI - thanks to @melpon - Dialyxir now supports a way to ignore known warnings.


I’ve come across this too.

The output says Dialyzer is complaining because it can’t find the __impl__/1 functions.

I figure it can’t find them because Dialyxir only tells it to look in the ebin directory by default (see the Path section in the README). Protocols are “consolidated” and the .beam files make their way into a consolidated directory under _build.

I resolved the warnings by adding the following to my Dialyzer configuration (with the above in mind):

      paths: [

This way I thought it’d know where to find them. I does resolve the warnings but…

I can’t find the modules it complains about. Not sure how it resolves the warnings but it looks like a good solution to me

@Joseph, isn’t that true, that when you add /consolidated to paths, you loose default /ebin inclusion? But if you try to include /ebin as well, Dialyzer complains about duplicate modules.

It seems that it would solve the problem to generate stubs for built-in types inside defprotocol macro.

@jeremyjh , Thanks a lot!

Using your “ignore_warnings:” config parameter I’ve suppressed “:0: Unknown function … :‘impl’/1” warnings. I used string “’:‘impl’/1” to filter them out.

Still, it would be great to have defprotocol macro updated so that it could make Dialyzer happy without workarounds.

Best regards

As I wasn’t able to find one on a first glance, you should probably be the first who opens a ticket at github.com/elixir-lang/elixir

But please check first if this happens for consolidated protocols as well as unconsolidated.

Perhaps it is simple enough to just make dialyxir use a dialyzer environment per default, that does (or does not) consolidate protocols.

@NobbZ, thanks!
Well, I used

def project do
  consolidate_protocols: false

to switch off consolidation - and still get the same error.

Here is the ticket: https://github.com/elixir-lang/elixir/issues/7708