The issue was that when `values` was used with a single input, that input was being forced too early.
Now code such as:
(! (letrec-values ([(x) (values (list y))] [(y) (values 1)]) (car x)) )
should produce 1 instead of #<undefined>.
Some simple test cases were also added.
The `vector->values` function set up multiple return values
badly in the case that the given vector is chaperoned.
The problem could lead to NULL as results for `vector->values`.
Merge to v6.1
Applying to a large number of arguments once causes the run-time
system to maintain a too-large buffer for managing tail calls in
the future. Decay the buffer size as it is reallocated.
Gemeralize Gustavo's change so that immediately-used right-hand sides
can be moved into any position that (like the binding context) enforces
single-valuedness --- for arbitrary right-hand expressions.
simple ->i contracts
specifically, ones with no dependency. This is useful for
when there are dependent #:post conditions (which can't be
expressed with the other combinators)
The protection against unsafe-function references was designed for
bytecode that referred to unsafe operations indirectly, and that
was broken when the compiler changed to refer to unsafe functions
directly in bytecode (to simplify JIT inlining bytecode optimization).
Actually, the relevant code (now removed) seems to be pointless,
since protected-binding checking should cover it already. Maybe
something else changed, or maybe the code was not properly checked
in the first place.
Now, `read` rejects a bytecode stream if it contains a direct
reference to an unsafe function and the code inspector is not the
original code inspector. It's still possible to synthesize bytecode
that contains an indirect reference, and then protected-binding
checking does its job.
original commit: 7ccac3c054
The protection against unsafe-function references was designed for
bytecode that referred to unsafe operations indirectly, and that
was broken when the compiler changed to refer to unsafe functions
directly in bytecode (to simplify JIT inlining bytecode optimization).
Actually, the relevant code (now removed) seems to be pointless,
since protected-binding checking should cover it already. Maybe
something else changed, or maybe the code was not properly checked
in the first place.
Now, `read` rejects a bytecode stream if it contains a direct
reference to an unsafe function and the code inspector is not the
original code inspector. It's still possible to synthesize bytecode
that contains an indirect reference, and then protected-binding
checking does its job.
While `catalog-archive` cannot handle arbitrary corruption of
a previous archive run, it should be able to handle a state
due to interruption or other transient errors.
Merge to v6.1.
