For some reason, when unifying a function call parameter with an
argument, subsequent calls to the same function will only accept the
type of the substituted argument.
This affect snippets like:
```
def make1() -> C[Literal[1]]:
return ...
def make2() -> C[Literal[2]]:
return ...
def consume(instance: C[Literal[1, 2]]):
pass
consume(make1())
consume(make2())
```
The last statement will result in a compiler error, as the parameter of
consume is replaced with C[Literal[1]].
We fix this by getting a snapshot before performing unification, and
restoring the snapshot after unification succeeds.
All allocas for temporary objects are now placed in the beginning of the
function. Allocas for on-temporary objects are not modified because
these variables may appear in a loop and thus must be uniquely
represented.
old_loop_target is only assigned if ctx.loop_target is overwritten,
meaning that if ctx.loop_target is never overwritten, ctx.loop_target
will always be overwritten to None.
We fix this by only restoring from old_loop_target if we previously
assigned to old_loop_target.
In LLVM, i1 represents a 1-byte integer with a single valid bit; The
rest of the 7 upper bits are undefined. This causes problems when
using these variables in memory operations (e.g. memcpy/memmove as
needed by List slicing and assignment).
We fix this by treating all local boolean variables as i8 so that they
are well-defined for memory operations. Function ABIs will continue to
use i1, as memory operations cannot be directly performed on function
arguments or return types, instead they are always converted back into
local boolean variables (which are i8s anyways).
Fixes#315.
Previously, the final value of the target expression would be one after
the last element of the loop, which does not match Python's behavior.
This commit fixes this problem while also preserving the last assigned
value of the loop beyond the loop, matching Python's behavior.
