Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make dialyzer output more user-friendly #2603

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

ylh
Copy link

@ylh ylh commented Aug 2, 2021

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
Copy link
Collaborator

ferd commented Oct 30, 2021

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
Copy link
Contributor

filmor commented Feb 21, 2022

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
Copy link
Contributor

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
Copy link
Author

ylh commented Feb 22, 2022

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
Copy link
Contributor

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
Copy link
Collaborator

ferd commented Feb 22, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants