At this point the legacy chunk and the original `Code.get_docs/2`
implementation is still in place, but the tests have been adjusted to
exercise `Code.fetch_docs/1` instead.
If I got it right, one of the reasons for that change was to get the message:
> invalid expression in guard, **!** is not allowed in guards. To learn more about guards, visit: https://hexdocs.pm/elixir/guards.html
instead of:
> invalid expression in guard, **case** is not allowed in guards. To learn more about guards, visit: https://hexdocs.pm/elixir/guards.html
This change should make the test suite more robust for future changes or refactors :)
In addition, I've split a couple of strings that were exceeding the maximum line length (98). By the way, should the formatter warn when it cannot keep the code under the desired line length? maybe with a `--strict` flag?
This starts with an initial implementation of the `blame/2` callback
for `KeyError` to add some helpful `did_you_mean` feedback for
potentially typo'd keys. Right now it's only implemented for maps and
keyword lists, and only for atom keys.
The optimize_boolean option is very sensitive to the order of
clauses and the optimisation was not happening for and/2 and or/2.
Add regression tests to ensure that won't happen again.
Removes tests that dialyzer does not emit warnings for optimised
and and or - those warnings could actually be helpful.
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.
* Add failing test for Base.decode32!/2 throwing a case error instead of an argument error (Issue #7703)
* Fix Base.decode32!/2 throwing a case error instead of an argument error when using :mixed case (Issue #7703)
The original issue (#7647) was posted in a very specific context, but I
figured that this implementation would both address that issue as well
as provide helpful feedback if someone were to attempt to write types
with variables incorrectly in general, since that was what was being
raised here.
I've also added more tests to ensure
that we're catching all these cases. All the allowed cases were already
covered extensively in tests, so we're good on that front.
Resolves#7647
Erlang/OTP 20 warns if the stacktrace is read outside of a
catch/rescue. This commit mirrors this behaviour by consistently
warning on `System.stacktrace/0` being used outside of a
catch/rescue.
Erlang/OTP 21 warns whenever System.stacktrace/:erlang.get_stacktrace
are used. Therefore we need to promote the usage of `__STACKTRACE__`
and make sure to conditionally compile it according to the OTP version.
This requires changes to the Exception normalization mechanism
so we compute `__STACKTRACE__` only when strictly required.
In future Elixir releases, `System.stacktrace/0` will warn when
used even inside catch/rescue.
We were not testing "var in [Alias1, Alias2]" but only "var in
[Alias1]". I noticed because changing the compiler to compile that to
var.__struct__ == Alias1 and var.__struct__ == Alias2
would still pass tests for Kernel.RaiseTest.
José Valim
László Bácsi
Adrian Cruz
Alex Castaño
Fernando Tapia Rico
Devon Estes
Sihui Huang
Michał Muskała
lukevmorris
Derek Kraan
René Föhring
Tonći Galić
Idean
Glauber Campinho
Eksperimental
Aleksei Magusev
José Valim
Andrea Leopardi
Zacck Osiemo