Today the formatter still uses some private APIs
and this commit aims to expose some of them.
In particular, Macro.classify_atom/1 was added to
expose if an atom is an alias, an identifier, quoted,
or unquoted.
Note that the API does not say anything about
operators, since they can fall within three distinct
categories:
* unquoted and callable, such as, `+`, `-`, and
most operators
* unquoted and not callable, such as, `.`, `..`,
and `..//`, which would be ambiguous when used
as `Module.OP()`
* quoted but callable, such as `::`, which is
ambiguous in the atom syntax but not as calls
This information still remains private, especially
because most times operators are used, we often still
want to learn about their precedence too.
We also exposed `inspect_atom/2` with three
distinct clauses to cover the different scenarios
atoms can be inspected at runtime and in source
code.
And vice-versa.
Overriding a macro as a function (and vice-versa) might produce
undesired effects.
For example, it's not clear if the following code should or
should not raise:
defmodule Foo do
def foo, do: bar()
defmacro bar, do: :ok
defoverridable bar: 0
def bar, do: :ok
end
On top of that, `super` does not currently work for such cases.
This is part of an ongoing effort to forbid overriding macros
with functions and vice-versa. New checks will require the
overridable information to be stored more efficiently.
Previously we kept a Set table for attributes and a Bag table
for function definitions and clauses. This led to suboptimal
usage of ets tables.
With this commit, we start using both Bag and Set tables
to store function/macro definition information. In the next
commits we will continue generalizing the tables, storing
specs, docs and accumulated attributes in the Bag and keep
the remaining functionality in Set.
José Valim
Ioannis Pinakoulakis
José Valim
Fernando Tapia Rico
Glauber Campinho
José Valim
Sam Davies