Normalize compile errors and warnings

20 views
Skip to first unread message

Mijail Rondon

unread,
Nov 27, 2019, 12:57:00 AM11/27/19
to elixir-lang-core
Hello Elixir Core,

Currently we have different ways to display errors or warnings during compile time, we should normalize the output.

For example, warnings are displayed as:

warning: unused alias Stream
  lib/actions_sample.ex:2

and compile errors as:

** (SyntaxError) lib/actions_sample.ex:15: unexpectedly reached end of line. ...

So, no problem with compile errors but warnings should have the same format as:

** (Warning) lib/actions_sample.ex:2: unused alias Stream

The main reason to make this change is because in CI we have the ability of catch those warnings or errors
and add annotations on specific lines of the corresponding files.

If we normalize the warnings this will be possible to add annotations of warnings to.

Mijail Rondon

unread,
Nov 27, 2019, 1:11:30 AM11/27/19
to elixir-lang-core
I think i can make the change for that.

Is on lib/elixir/src/elixir_errors.erl

Louis Pilfold

unread,
Nov 27, 2019, 2:59:26 AM11/27/19
to elixir-lang-core
Hello!

What prevents the tool from attempting to parse both formats and using whichever succeeds? That way this feature can exist without any changes to the compiler.

Cheers,
Louis

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/491c2a71-560e-4df3-9547-98696502aaf8%40googlegroups.com.

Mijail Rondon

unread,
Nov 27, 2019, 3:10:32 AM11/27/19
to elixir-l...@googlegroups.com
There is not a prevention to parse both formats but also there is not a reason to have 2 formats.

Currently to handle the warnings and errors anyone who want to do that have to create 2 regex to handle each one, with one format you only need one.

I think there is not a problem if we normalize that.I'm facing that problem in Github Actions in this pull request: https://github.com/actions/setup-elixir/pull/11
And i will be glad to make a collaboration in the core of elixir if you all allow me to do so.

Louis Pilfold

unread,
Nov 27, 2019, 6:06:24 AM11/27/19
to elixir-lang-core
I agree there may not be any reason to introduce more formats, but Elixir is now stable so we may want to think twice before we change any existing output formats.

I quite like the idea of having a flag that can be given to cause all output to be emitted in a structured format (such as JSON or the textual Erlang term format) so it can be easily read by tooling and possibly contain extra information that would be distracting for normal human viewers.

Cheers,
Louis

eksperimental

unread,
Nov 27, 2019, 7:55:24 AM11/27/19
to elixir-l...@googlegroups.com
> Currently we have different ways to display errors or warnings during
> compile time, we should normalize the output.
I would say currently there is one way to displays errors and one way to display warnings.

I think it is important to keep different formats to visually differentiate them with ease.

José Valim

unread,
Nov 27, 2019, 8:32:59 AM11/27/19
to elixir-l...@googlegroups.com
Correct. We had this discussion before and we reached some important conclusions:

* warnings and errors should be visually distinct

* output should favor human readability rather than being parseable by machines

* because compiling Elixir code is the same as running Elixir code, compilation can fail due to runtime errors, and those will always have a full stacktrace. This is a contrast to syntax errors, which always point to the source location

Given these reasons, we introduced a diagnostics API in Mix that returns structured data so it can be output in any format of choice. Perhaps it is worth giving it a try.
--


José Valim
Founder and Director of R&D

Mijail Rondon

unread,
Nov 27, 2019, 1:57:16 PM11/27/19
to elixir-l...@googlegroups.com
Oh, I get it, thanks for the replies and explanation.

Thinking about it, you are right, because is not a machine making the code, it is a human. So the machine should be able to parse that, it's not hard.

I make a change in the PR of GitHub Actions to parse warnings too. https://github.com/actions/setup-elixir/pull/11/files#diff-c7e14e438b8ad4681d53486826a1b81b

Reply all
Reply to author
Forward
0 new messages