make dialyzer output more user-friendly

[ylh]

While the current output is pretty, it violates a convention that is obeyed when running rebar3 compile and friends, namely, the $file:$line(:$col)? format. Many tools that take shell output, from text editors to certain terminal emulators, have some degree of support for interpreting compiler errors that follow this convention as “links”. This PR would change output that looks like this:

apps/example/src/example_db.erl
Line 192 Column 5: Call to missing or unexported function foo:bar/2

apps/example/src/mod_foo.erl
Line 29 Column 1: Function real_do/1 has no local return
Line 95 Column 1: Function combobulate/4 will never be called

apps/examplesrv/src/examplesrv_widget.erl
Line 9 Column 8: The created fun has no local return
Line 15 Column 1: Function build_view/1 has no local return

to output that looks like this:

apps/example/src/example_db.erl:192:5: Call to missing or unexported function foo:bar/2
apps/examplesrv/src/mod_examplesrv.erl:29:1: Function real_do/1 has no local return
apps/examplesrv/src/mod_examplesrv.erl:95:1: Function combobulate/4 will never be called
apps/examplesrv/src/examplesrv_widget.erl:9:8: The created fun has no local return
apps/examplesrv/src/examplesrv_widget.erl:15:1: Function build_view/1 has no local return

Thoughts?

[ferd]

I don't know that I prefer the new suggested format for human readable content, but it's hard to argue it would be worse for machine-readable format.

If anything it would be a misnomer to call it more 'user-friendly', ultimately it's about script-friendliness. I'm wondering if we should shift to that format only optionally, when we know we want a device to handle the output.

[filmor]

The proposed format would be very useful in the context of IDEs (like VSCode) which can interpret path:line:column entries like this and allow you to navigate to the location of the error quickly from the embedded terminal.

[paulo-ferraz-oliveira]

I'm wondering if we should shift to that format only optionally, when we know we want a device to handle the output.

I think this would be a good compromise, an option. My 5c.

[ylh]

If anything it would be a misnomer to call it more 'user-friendly', ultimately it's about script-friendliness.

With respect, I'd have to take issue with that.

The proposed format would be very useful in the context of IDEs (like VSCode) which can interpret path:line:column entries like this and allow you to navigate to the location of the error quickly from the embedded terminal.

Yep, I chose the wording of the title carefully, and this is what I was on about with “user-friendly” -- to me, in this context, “script-friendliness” for its own sake is secondary to following existing UX idioms in developer tools.

Off the top of my head, the first-party Erlang toolchain, GCC, Clang, GHC, rustc, and the Go compiler follow the convention, and several of those still make room for big friendly messages with colour codes and arrows pointing to offending columns.

I'm certainly open to making this a config option, though considering how the rest of the Erlang tools behave (even when being called by rebar3!) I think making the default consistent with those would be a good idea.

[paulo-ferraz-oliveira]

following existing UX idioms in developer tools

I, for one, consume the results of rebar3 dialyzer from the shell. Even if I do understand the output with all : and the like, it's surely easier to human-read the results if they contain words like "Line" and "Column". Another example of a tool that builds on top of rebar3 and has parsable output is rebar3_lint (by default, the output isn't "parsable"), but there is an option to make it so.

Breaking compatibility by changing for format of the output, in rebar3, is also possible, but there may be tools out there (including company-internal ones 😉) that already make do with the format that exists.

[ferd]

The readability change is not just from the column format but also from moving from:

Filename1
Error1
Error2
Error3

Filename2
Error4
Error5
Error6

And going for

Filename1:Error1
Filename1:Error2
Filename1:Error3
Filename2:Error4
FIlename2:Error5
Filename2:Error6

Which, depending on how you lay out your paths (apps/my_long_app_name/src/sub_component/sub_path/my_long_app_name_sub_library.erl), gets to be extremely cumbersome. That one, in my mind is clearly more about tool usability than actual readability.