Blog Post: Adding Dialyzer without the Pain

but it’s worth mentioning that ignoring new errors is completely valid as well.

It’s also worth mentioning that dialyzer will not analyze beyond errors because that state is absurd and cannot be reasoned about: ignoring the error merely suppresses the message. This can suppress other errors or magically bring new and incredibly difficult ones into existence.

Warnings like those for constructing “improper” lists are safe to ignore, but I don’t recommend ignoring errors. By all means, feel free to tackle the problems one at a time, but shoving them under the rug by placing them in an ignore-file can make other errors needlessly difficult to diagnose.

I’ve been in discussions with my team about adding dialyzer to our codebase. I like the approach you outline in the article, however I do have a question. Let’s say we have a file that it’s ignored. Now, some code is added to that file and that new code has an error. Is there a way to have dialyzer warn about this? AFAICT we only have 2 options:

1. Ignore specific lines. This seems like a maintenance nightmare as line numbers will have to be kept in sync.
2. Ignore specific error types. This kind of works, but would break if the error is the same type as a previously ignored error.

Once we get to 0 errors, this will solve itself out, so I’m not super concerned, but I just wanted to get some input from the experts.

Thank you!

Let’s say we have a file that it’s ignored. Now, some code is added to that file and that new code has an error. Is there a way to have dialyzer warn about this?

One thing you can do is:

# .dialyzer_ignore.exs
[
  {"lib/something.ex", :no_return},
  {"lib/something.ex", :call},
]

Now, if you introduce new errors to lib/something.ex, as long as it isn’t a :no_return or :call error, it will still get caught. However, if you do add a new :no_return error to the file, it will get ignored unfortunately.

Another option is to use regex patterns (which I’ve not experimented with much), like so:

# .dialyzer_ignore.exs
[
  ~r/my_file\.ex.*my_function.*no local return/
]

With this, you could refine the ignored error to a specific function/error combination.

However, I created a PR to add a more strict ignore file format, and it’s been merged. It should come out in the next release of dialyxir.

Also, one helpful method to partially address the weaknesses of the ignore method that @jhogberg pointed out is:

1. Delete all ignored lines from the .dialyzer_ignore.exs file.
2. Run mix dialyzer again.
3. Fix whatever errors you can (or are willing to). Maybe isolate your quest to a single file/module at a time.
4. Regenerate an ignore file and add those lines to the ignore file again. This should hopefully now be a smaller file than it was previously.