Dialyxir Pretty Printing: All your errors are belong to us (please)!

dialyzer
dialyxir
Tags: #<Tag:0x00007fbcabf666b0> #<Tag:0x00007fbcabf663b8>

#1

Hi everyone,

Andrew Summers has been working on a feature for dialyxir that among other things will Elixirfy the Erlang term representations - in particular this will improve the readability of structs in dialyzer warnings. It also gives us the ability to tweak or expand on the wording of the messages.

Ideally we’d have a test suite based on a corpus of real-world warning messages - but that doesn’t really exist to my knowledge. This is at the point though that alpha testing would be helpful to identify cases where types are not parsed when they could be or fail when attempted.

If you’d like to help out, and your project is already using Elixir 1.6 (we rely on this to help with pretty printing) you can update your mix.exs to use this branch:

{:dialyxir, git: "https://github.com/jeremyjh/dialyxir", branch: "elixir-formatter", runtime: false}

If parsing fails with an exception dialyxir should automatically print the message using :dialyzer formatter (like it the released version does today). If that happens please post about it in the PR.

Also there is a new command line option --raw - if you see output that you think doesn’t look good or doesn’t parse things that want for parsing, please re-run with mix dialyzer --raw and post the output tuples to that PR.

Thanks in advance!


#2

This feature has merged to master - I really want to thank Andrew for all the work he’s put into this.

Also, I wanted to mention another feature Andrew added, which is --explain - this contains help text about what the class of warning means. So mix dialyzer --explain no_return will now do exactly that. Suggestions / improvements to this learning resource would be greatly appreciated.


#3

Thank you everyone for your bug reports and patience as I fixed them :smile: Please make issues with any unclear language or issues you might still be having! I think the output is substantially more readable, and encourage you to play around with it. The --format short option is particularly nice for CI pipelines.


#4

All of this sounds really interesting and useful and the output is already much more readable then the previous output. Quick question, is it possible to get the --explain output available via iEX?


#5

Totally should be. Are you thinking in an editor capacity? Can you make an issue and we can work out the details.


#6

Actually you can just invoke the explain/0 function in all the Dialyxir.Warnings modules.

iex(3)> Dialyxir.Warnings.BinaryConstruction.explain()

There currently isn’t an accessible list of all available warnings, but that should be trivial to throw behind a function.

Curious what the use case is though, we might be able to do better.


#7

That function doesn’t appear to be quite what I’m thinking. This is what I get:

iex(1)> Dialyxir.Warnings.BinaryConstruction.explain()
"This warning type does not have an explanation yet. If you have\ncode that causes it, please file an issue or pull request in\nhttps://github.com/jeremyjh/dialyxir/issues\n"

When I would want to be able to run something more like this:

iex(1)> Dialyxir.explain("no_return")
"The function has no return. This is usually due to an issue later
on in the call stack causing it to not be recognized as returning
for some reason. It is often helpful to cross reference the
complete list of warnings with the call stack in the function and
fix the deepest part of the call stack, which will usually fix
many of the other no_return errors.

defmodule Example do
  def ok() do
    Enum.each([1, 2, 3], fn _ -> raise \"error\" end)
  end
end

or

defmodule Example do
  def ok() do
    raise \"error\"

    :ok
  end

  def ok(:ok) do
    ok()
  end
end"

The use-case is either just accessing the explanations via iEX manually while coding, as well as I can forsee it being useful for an editor integration.


#8

Right, so that one is just missing an explanation. if you call:

iex(7)> IO.puts Dialyxir.Warnings.NoReturn.explain()
The function has no return. This is usually due to an issue later
on in the call stack causing it to not be recognized as returning
for some reason. It is often helpful to cross reference the
complete list of warnings with the call stack in the function and
fix the deepest part of the call stack, which will usually fix
many of the other no_return errors.

defmodule Example do
  def ok() do
    Enum.each([1, 2, 3], fn _ -> raise "error" end)
  end
end

or

defmodule Example do
  def ok() do
    raise "error"

    :ok
  end

  def ok(:ok) do
    ok()
  end
end

:ok:

I think it will do what you want. I’m not sure how to force it to respect the new lines besides IO.puts.


#9

But from an output like:

apps/web_interface/lib/web_interface/controllers/api/page_controller.ex:47:no_return
Function join/2 has no local return.

How is a user supposed know that maps no_return maps to Dialyxir.Warnings.NoReturn?


#10

Totally fair question, that part is missing :slight_smile:


#11

@axelson Added Dialyxir.Warnings.warnings/0 that will give the atom to module mapping, so you can to_string or whatever else you need to do from there. Also adds a --list option to just see them in general. Please open a GitHub issue if that isn’t sufficient :smile: :heart:


#12

Thanks that looks very useful!


#13

I’ve published a release candidate to hex:

  {:dialyxir, "~> 1.0.0-rc.0", only: [:dev], runtime: false}

We also made a minor API change from the preview, dialyzer.explain is a new top-level task that replaces --explain and --list.