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:
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.
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.
Thank you everyone for your bug reports and patience as I fixed them 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.
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?
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.
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.
@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
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).
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.
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…
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.
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 
