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

dialyzer
dialyxir
Tags: #<Tag:0x00007fcf98083670> #<Tag:0x00007fcf98083530>

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


#14

@jeremyjh what’s left / what help could you use to make 1.0.0 ready for prime time?


#15

Hi, we are really close, but have had a few issues slowly trickling in. The plan is to push another RC tomorrow and a final 1.0.0 a week from tomorrow (July 6th).


#16

My experience running the beta was pretty good. The only issues I ran into was related to integration with Vim (through Ale). It just isn’t configured to display the new warning format yet.

Nice work all around, excited for this improvement to our tooling.


#17

Thats what I like about the Elixir-LS. It calls into dialyzer itself and annotates the code. I’m eagerly waiting for the LS to integrate dialyxirs pretty printer, as dialyzer tooltips in the LS are in erlang form…


#18

If Ale is running mix dialyzer and displaying errors in the editor, it needs to pass --format short most likely.


#19

Are you using LS through Vim/NeoVim? Apparently Ale is adding LS support, but I haven’t taken the time to enable it yet.

Good to know. Is that a 1.0 only option or can it be passed currently? I’m sure they’ll want to maintain backward compatibility for dialyxir 0.5 as well.


#20

No, via VScode. But I’ll try to enable it in Emacs during next week.