While working on a tool that processes Erlang code and testing it against this repo,
I found out about those little sneaky 0xff. I thought it may be of help to other
people build such tools to remove non-conforming-to-standard characters.

Commit 60984ade updated the code, but not the type spec.

Noticed-by: Kostis Sagonas

ErrorInfo is documented to be:

  {ErrorLine,Module,ErrorDescriptor}

but for some errors with line numbers it would look like:

  {Module,ErrorDescriptor}

Ensure that all ErrorInfo tuples have three elements. Use 'none'
instead of a line number:

  {none,Module,ErrorDescriptor}

There already are errors that return 'none' when no line number is
available, but that convention was not documented. Mention it in the
documentation.

Also make sure that the compiler will not print 'none' as a line
number in error messages (if the 'report_errors' option is given) as
that looks stupid. That is, when attempting to compile a non-existing
module, the error message should be:

  non-existing.erl: no such file or directory

and not:

  non-existing.erl:none: no such file or directory

By Erik Stenman (happi) with corrections by me.

* nox/match-context-return/OTP-11247:
  Added primary bootstrap
  Forbid returning a match context in beam_validator

If a match context is returned from a function without being converted
back to a plain old binary, the whole VM will crash.

* nox/fix-comp-warnings/OTP-11212:
  Bootstrap
  Silence a misleading warning with some comprehensions

Local fun references look like plain old variables in the Core Erlang
AST but should not be treated as such. Inlining of such expressions is
now restricted to application contexts as a local fun reference should
never occur in a guard.

This is not perfect as it forbids inlining in some safe situations, but
that is still better than a compiler crash.