We also extend Mix.Tasks.Compiler.Diagnostic
to include {line, column} as possible position.
We also explicitly document the behaviour of
line=0, which is equivalent to unknown line.
Elixir was already setting the line to zero in
multiple occasions prior to this patch, so this
patch makes it official and we stop returning `nil`
for said cases.
The Elixir compiler spawns a separate process per file.
When a file has to wait on another module, Elixir tracks
in the compiler that the file is waiting.
However, every time a module is defined, the Elixir compiler
spawns a separate process to compile to .beam, and this
process may expand structs in the typespec. Since this
new process is no longer the original file process, Elixir
was not able to track its waiting time.
This PR address this issue by passing the original file_pid
to the .beam compiler process. Note though that, if we
change typespecs to be compiled in the original file process,
this change is no longer required, but at the moment there are
no plans to make such change.
Closes#11036.
* fix dialyzer issue in ParallelChecker.verify/2
* fix dialyzer specs for elixir_errors:form_error and elixir_errors:form_warn
* fix dialyzer error caused by erl_anno:anno type being opaque in exception.ex
* fix spec for File.stream!
* fix spec for IO.getn/2 - dialyzer doesn't support overloaded specs
* add explicit spec for System.halt/0 to fix dialyzer error
* fix spec for Regex.recompile/1
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.
We avoid using :file publicly as well as :location privately.
We do still use :file privately but that's supposed to mirror
the `-file` annotation in Erlang before function definitions.
Vinícius Müller
Jean Klingler
José Valim
Andrea Leopardi
felipe stival
Michał Łępicki
Eric Meadows-Jönsson
Eksperimental
Wojtek Mach
José Valim
Michał Muskała
Jake Becker
Alex Jiao