We can't disallow the creation of bad mutators without breaking
old code, but we can prevent the JIT from treating them like
good ones.
Closes PR 13062
Since SIGHUP normally means that the output has gone away,
don't try to write to it.
Closes PR 13058 (although it doesn't solve the more general
problem that is noted in the PR)
The bytecode compiler used to convert an expresison like
(<flonum-op> <simple-expr> <complex-expr>)
to
(let ([id <complex-expr>])
(<flonum-op> <simple-expr> id))
to help an older version of the JIT avoid boxing the result of
<simple-expr>, but that transformation isn't needed, since the JIT can
keep unboxed values on the stack.
The transformation was complex and apparently buggy.
The changes also include a repair to the JIT for code that the
bytecode compiler formerly wouldn't generate, but which is allowed
bytecode.
Closes PR 13052
Generalize splitting of `(let-values ([(x ...) (values e ...)]) ....)'
to `(let ([x e] ...) ....)' for any `e', since it's always equivalent.
Right?
(The old requirements on the `e's seem to be needed only for
`letrec-values' splitting and maybe mutable variables.)
Treat unsafe functional operations (which never raise an
exception) as omitable, which means that simple `let-values'
combinations can be split into `let' bindings, etc.
corner of the definitions window, based on the information that check
syntax computes
This commit contains two separate changes to make this work:
- adding a new renderer, based on the text renderer, that
pulls out the contents of the blue boxes and saves them
in the doc/ directories (specifically in the files named
contract-blueboxes.rktd)
- extend check syntax to use and display the information
build by the new renderer
Internally, there's a `prop:method-arity-error' property that is
used for keyword-accepting methods. The same thing could be
accomplished with `procedure->method', but the new property avoids
a wrapper. It might be nice to expose the property from `racket/base',
but that creates trouble for generating arity errors for keyword-
requiring procedures (i.e., when such a procedure is wrapped), so
keep it provate for now.
Closes PR 12982
A progress evt from a close input port must be initially ready,
and the primitive `peek-bytes-avail!' checks a progress evt
before checking whether the port is closed.
These changes resolve a race in `read-bytes-evt' and related evt
constructors.
Fix tchecking for a rest argument to a function that
is lifted by closure conversion so that one of its
arguments is a mutable local variable's location.
Also reject bytecode that would pass too many arguments
to a lifted function, since that would trigger an arity
error that might try to use a location as a value.
Merge to v5.3
When a `port-commit-peeked' succeeds, position information should
(appear to) be updated. This patch synchronizes commits and
position information for primitive ports, but synchronizing
them for user ports remains a problem.
When `guard-evt' or `nack-guard-evt' is used, `sync' didn't
account for the possibility that a channel or semaphore
action might complete during the call to the guard, in which
case it might fail to select the event that has already
completed.
Merge to v5.3
