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.
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
> 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
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
Good call!
What if we simply convert any line where = is the root expression and the
left-side is not a variable to an assertion?
The rationale is that this is an ok doctest:
iex> {:error, _} = do_something(var, 0)
iex> :ok = do_something(var, 1)
And we would most likely want to raise
I think doctests are extremely helpful and powerful since they encourage
developers to write testable, accurate documentation for their code. But
the lack of some of the niceties that exist in ExUnit might make it less
likely for developers to choose doctests instead of ExUnit tests, so I've
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
