To get the expected contents of the various environment variables, I
used a similar approach to what the build does in `grab_batch_vars':
* Start a cmd.exe shell (not a real shell)
* Dump the env into a buffer
* Run "... Studio/VC/vcvarsall.bat" (modifies envvars, which is why cmd
is needed)
* Dump new env into a new buffer
* Sort both buffers and compare
Hopefully it still works also on Matthew's setup.
Two other small things:
* Use ".obj" suffix on windows to avoid warning.
* Catch error when trying to delete the .so file, since on the x86_64
machine it throws an error. (I'm not sure how it *doesn't* do that
with the i386 machine.)
Certain `lambda'-lifting operations can cause information
about the flonumness of a variable to get lost, leading
to a mismatch between the closure's flags and flags on
a variable reference. (The bytecode validator could detect the
bug when loading the broken bytecode. The broken information,
meanwhile, was only used by the JIT.)
The two became tangled in commit f7c16fc8, and then 952ae06105
adjusted the tangling in a way that broke code. This commit
further adjusts tangling in a way that hopefully causes fewer
compatibility problems, but it also splits inputs to
`make-evaluator' so that a programmer can choose more explicitly.
coloring for blame assignment in check syntax) try to color
the right-hand side of a binding that actually comes from
a lambda-bound variable (and thus crash for not finding the
right-hand side)
The generated code was checking arity after potentially copying
arguments to the start of the runstack (i.e., if the arguments
were not already there). If too few arguments are provided, then
the copy might access past the end of the given array.
The redundant arity check removed in commit f7c506471b
had previously masked this problem. (Or the check wasn't redundant
in that sense, but it's better this way.)
Merge to 5.2.1
Certain unsafe operations were allowed to propagate across a
`lambda' boundary (where space safety is known not to be an issue),
which could lead to duplicate uses of a "once used" variable if
the relevant `lambda' is inlined.
Furthermore, `lambda' boundary crossing wasn't detected in the case
that the operation to propagate was propagated through an intermediate
variable without a `lambda' crossing.
Merge to 5.2.1
