TTo keep stack alignment correct, the `objc_msgSendSuper_stret`
function needs to be used with a structure return type on i386,
instead of making the implicit return-pointer argument explicit.
(For BC, libffi apparently makes the wrong style work anyway.)
A wrapper to align the stack during activation was dropped if the
return type was `void` for a foreign callable, and a callee-popped
argument was not handled right for a foreign call.
It's not necessarily ok to inline a function wrapper by
`make-wrapper-procedure`, because the wrapper might get mutated. We
could add immutable wrapper procedures, but we can also just revert to
a previous approach for code that needed the optimization.
* Initialize the environment variables with paths to
MSVC toolchain before running the racket-test-core,
since the foreign library tests need a C compiler.
* Fix a bug in foreign-test.rktl that deletes the existing
content of environment variables (PATH, INCLUDE, LIB, etc)
* Let a test in date.rktl fail more gracefully.
Currently, this repair matters only for PPC32 Mac OS, which is the
only place where alignment of some primitive atomic type is not the
same as its size.
The non-standard ARM Mac OS ABI doesn't just use a different
convention if the function has varargs: it puts each vararg in a
different place than a non-vararg argument of the same type and
position. So, `foreign-procedure` and `foreign-callable` need to know
where varargs start. A `__varargs` declaration is shorthand for
`(__varargs_after 1)`.
For PPC32 Mac OS, we retain the trick that makes varargs foreign calls
work without a `__varargs` declaration, but `(__varargs_after <n>)`
fixes up callable support --- in the extremely unlikely case that
someone needs general varargs callables on PPC32 Mac OS.
Since Chez Scheme now performs the kind of closure conversion that
Racket does --- ensuring that a closure is not allocated if it is
bound to an identifier that is used only in application positions ---
the variant in schemify is not longer run. The hacky macro-based
lifter in the "rumble" layer can also go.
The lifting pass is still preserved in schemify, because it is still
useful to cify. It's not clear whether interpreter mode (which is used
during macro expansion for compile-time code that doesn't cross a
module boundary) is better off with or without schemify's lift, but
it's gone for now.
This commit fixes two bugs:
* `sync/enable-break` didn't implement the guarantee that an event is
selected or a break exception raised, but not both; the problem was
in the handling of making the break-enable state ignored after
committing to an event
* `sync` didn't cancel asynchronous pending commits when a break is
received at certain points; the bug in `sync/enable-break` masked
this bug for existing test cases
Closes#3574
A seemingly-unintentional choice made the following not behave
as expected:
(define-inline (f x) (+ x 1))
(f (f 2))
because the `(f 2)` was not inlined.
Reported by @mflatt and Liwei Chou.
The function make-temporary-file supplies a string
argument consisting of digits to the format function.
Therefore, if the template uses the ~s formatting
escape, make-temporary-file will attempt to create
a temporary directory with double quotes in the path.
Such paths are now allowed on Windows.
Replace the vfasl writer (which was in C) with a new implementation
(in Scheme). The main result is that the vfasl writer can be used in
cross-build mode.
Racket uses the vfasl format for its boot images, because they can
load faster --- cutting the Chez Scheme plus boot files startup time
in half, which saves about 40msec on a typical machine. That's not
enough to matter for something like DrRacket, but it can matter for
small Racket scripts. Formerly, cross builds disabled vfasl
generation.
A vfasl file is roughly an image of code and data as it will appear in
memory, and a relatively fast linking step makes the image work in a
running process. The old implementation was in C because it reused GC
structures and code, treating fasl creation as copying objects into a
vfasl image instead of a new generation. The new implementation is
more like a fasl reader, loading objects into a vfasl image instead of
the live heap. The two implementations are about the same amount of
code and both involve a certain amount of repeated implementation
(i.e., imitating a collection or fasl load), but the Scheme
implementation is more flexible and works for cross compilation.
Reading `1.0e45` produced a different (and less precise) result than
`1e35`. The problem was in the reader's fast path for simple flonum
conversions, where it converts the mantissa and exponent separately
and then combines them. 10^44 is not represented exactly as a flonum,
so there's imprecision when multiplicy it by 10 versus multiplying
1e45 by 1.
Closes#3548
Callbacks from C generally need to be in atomic mode, but they don't
need to have interrupts disabled at the Chez Scheme level, because
that disables GC.
Without this change, dragging a scrollbar or resizing the window in
DrRacket would suspend GCs as long as the mouse button is pressed ---
which could allocate arbitrary amounts of memory fairly quickly
meanwhile.
Cross-library inlining is willing to inline a procedure body that
refers to a system primitive, but wasn't willing to propagate a
system primitive directly. Enable that, and use it to simplify
`unsafe-struct` inlining.
Related to #3546
Copy any syntax-original property from the parentheses assodictaed
with a `#%app` made explicit, so that originalness is tracked in
the 'origin property.
