This provides a more robust way of checking from where
the original expressions are coming from compared to the
lexical check_clauses field we had in elixir_scope.
A direct consequence of this commit is that, the following
code:
defrecord Sample, [:hello] do
import List
end
Now raises a warning if the List import is not used,
where it didn't previously.
* "default arguments in some_fun/3 are never used"
* "the first default argument in some_fun/3 is never used"
* "the first 2 default arguments in some_fun/3 are never used"
Closes#929
This means the second item in the AST is no longer an integer
(representing the line), but a keywords list. Code that relies
on the line information from AST or that manually generate AST
nodes need to be properly updated.
Previously, we were generating atom names based on
the file or the module name. This commit replaces
it by a pool of atom names. After a module name
is used and purged with success, it is added back
to the pool so it can be reused many times.
Previously, since the functions were not concrete
but stubs replaced at compilation time, we had to
special the module definition to not actually include
the specs, which would become compilation errors.
Now we provide a concrete implementation of the
functions and therefore the spec will be available
in the final source. Those implementations are not
actually invoked in practice, since they are still
transformed into erlang ones for performance reasons.
Previously, 58eea96fc2 was
attempting to solve the ambiguity of records and defmodule result.
This solves the problem completely by tagging defmodule results with
the :module atom and it brings the module name back into the tuple
We avoid returning { module, binary, result } because
it can be mistakenly confused as a record named module.
Before this patch, defrecord Foo, bar: nil, baz: nil
in IEx was returning:
Foo[bar: <<binary>>, baz: nil]
José Valim
Yurii Rashkovskii