We use this option in ExUnit as we are escaping
the code to eventually convert it to a string
representation and therefore the metadata is not
relevant.
When you are working on large files and you add new code,
you may forget to add a `do` or an `end`. In those cases,
the error message usually points to the first `do` or the
last `end` in the file, which are usually far away from
the source of the error.
This pull request adds a simple heuristic based on the
indentation of the tokens, to try to provide hints of
where the source may be. Those hints are not deterministic
but they may be able to point users to the source of the
problem.
For example, in this case:
defmodule MyApp do
def one do
# end
def two do
end
end
we know that we now that `def two do` is happening on the
same indentation as `def one do`, which may mean that
`def one do` was not closed properly. We store this as a
hint in case the terminators do not match later.
Similarly, in the case below:
defmodule MyApp do
def one
end
def two do
end
end
The `end` on line 3 will end-up closing the defmodule `do`,
on line 1. Because their indentation do not match, it may
be that there is a missing `do`, where the `end` was supposed
to align.
Some basic testing show those heuristics work on the majority
of the cases, but we will only be sure when we have enough
feedback from the community.
Change how we mark the generated AST for suppressing dialyzer errors -
instead of [generated: true, location: 0], we provide proper line number.
This means, however, that on OTP 18, those nodes won't be recognized
as generated and warnings will be issued.
It was decided that proper error messages are more important than
avoiding bogus dialyzer warnings.
The old mark for generated code is left in places that made compiler
issue warnings on 18.
The bad remote call dialyzer warnings can be suppressed with the
@dialyzer :no_fail_call
module attribute.
Pablo Costas
José Valim
José Valim
Łukasz Jan Niemier
Arjan Scherpenisse
Michał Muskała
José Valim
Alex Jiao
Aleksei Magusev