This introduces five new metadata nodes:
* `do` - contains metadata about do location in a function call with
`do/end` blocks
* `end` - contains metadata about end location in a function call with
`do/end` blocks
* `closing` - contains metadata about the closing pair, such as a `}`
in a tuple or in a map, or such as the closing `)` in a function call
with parens
* `eol` - is set to true when the opening pair, such as `{` or `(`, are
followed by the end of the line
* `delimiter` - contains the opening for sigils (such as `"{"`, `"/"`,
etc)
Today charlist interpolation is quivalent to calling `String.to_charlist`
on the equivalent string interpolation. It can be more efficient by
leveraging chardata support in the `:unicode` module and encoding as a
list of literal binaries and results of `Kernel.to_string` calls for the
interpolated segments.
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.
* Whitelist which operators support next_break_fits
* No longer consider tuples as part of next_break_fits
* Do not consider eol for = and ::
* Do not consider eol for calls with one next_break_fits arg
José Valim
José Valim
Eksperimental
Michał Muskała
Fernando Tapia Rico
Sihui Huang
Glauber Campinho
Andrea Leopardi
Eric Meadows-Jönsson