the errors documented here include cases where the error is detected
far away from where the actual malformed syntax is in the source file,
so any error message reported by the compiler needs to include enough
information to help the user find and resolve the error.
when both -a and -i switches are specified, ast nodes will be printed as they
are passed to the code generator, rather than all at once /before/ code
generation.
this makes it easier to determine which ast node is causing a code generation
error.
this allows value get_type callbacks to use mie_ctx to obtain mie_type pointers,
rather than having to define their own static versions of the type structs.
IVY_KW_VAR is not treated as an expression start token (as variable declarations are not
strictly expressions). so the lambda parser did not create a block parser context
when it encountered this keyword.
additionally, unnamed complex-msg args no longer need to be prefixed
with a colon. this allows complex-msgs to more closely emulate
traditional function calls. this also applies to the call-operator.
for example, take the following lambda:
var f = [ :x :y | ^x * 2 + y ].
before, this lambda would be invoked using the following syntax:
f(:2 :4).
now, this syntax is used instead:
f(2, 4).
some source files are recognised as objc source files due to the use
of array initialiser macros. because of this, the C/C++ formatting settings
defined in .clang-format weren't being used.
now, the correct settings are applied for objc files too.
the codegen scope system has been removed. instead, each generator state in the stack,
from the current state backwards, is informed when a variable is defined, resolved, or
captured.
when a variable is defined, the state stack is traversed back-to-front (current generator
first). each state has a chance to record the variable definition. once one state has
signalled that it has recorded the variable definition, the traversal ends.
when a variable is resolved, the state stack is traversed back-to-front (current generator
first). each state is asked whether or not it recognises the variable identifier being resolved.
if a state has the variable in question defined, it returns information about the variable
definition, and the traversal stops.
once a variable has been resolved, the state stack is traversed front-to-back (current generator
last), starting from the generator /after/ the one that provided the variable definition. each
generator in the iteration is given the chance to adjust the variable information, or generate
IR in response to the variable being accessed. this is used to implement variable capture,
where the state of a variable in the enclosing context is captured for later use.