* Track Elixir build warnings in the manifest
* Add --all-warnings option to Elixir compiler
* Document "each_warning" option in ParallelCompiler
* Handle old manifest version :v6 when parsing manifest
* Track warnings during compile using a map in the Agent's state
Standardizes the use of comma leaving a white space after it whenever applicable.
Note: It does not enforce this in quantifiers in regular expressions such as in: `x{1,3}`
Before this commit, we handled char literals (like `?a`) in the
tokenizer, turning a literal like `?a` into the token `{:number, _,
97}` (thus indistinguishable from the literal `97` at the parsing
stage). This led to error messages with the integer for the character
instead of the character literal, e.g.:
iex> :ok ?a
** (SyntaxError) iex:11: syntax error before: 97
With this commit, we now turn `?a` into the token `{:char, _,
97}` (which is the same token used by Erlang for Erlang char literals
like `$a`); since it's the same token as in Erlang, the parser will now
output the char literal as an Erlang char (`?a` would be printed as
`$a`). We hijack the error message in elixir_errors.erl to end up with
the correct message:
iex> :ok ?a
** (SyntaxError) iex:11: syntax error before: ?a
Add column info for each token in elixir_tokenizer.
Change the format of location info from `Line` to `[Line, BeginColumn,
EndColumn]`. Pass the current column after the current line in
`elixir_tokenizer:tokenize`. Reflect the change in related modules.
Since the guard can be hidden inside if/unless, it is better
to have a more generic error, stating we will always get the
same result from an check/guard.
We expose :elixir_errors.warn/2 and :elixir_errors.warn/3
The first is to be used when we have detailed caller information,
such as from a stacktrace. The second is useful when our only
context is a line number and filename.
Note also that the test for module redfinition is performed in
helpers_test.exs rather than in warning_test.exs Perhaps this is
something that should be moved.