To support module caching, module path indexes must be cloned
for each use of the cached module, so that path resolutions
don't collide. Cloning was previously implemented at the point
of shifting the modidx based on the module instantiation name,
but now its cloned at declaration time. This result in better
sharing of module-path resolutions, which in turn speeds up
compile-time instantiation of modules, which in turn speeds up
interactions & examples in documentation (as much as 10% for the
Guide, for example).
Furthermore, the reverse cache within a modidx may have been
used improperly during cloning, and that's not a problem in
the new implementation.
The JIT wants to detect calls to functions bound to module-level
variables that are always instantiated to a procedure of a particular
arity, in which case it can avoid some checks. The problem is that
bytecode and JITted code can be shared via the module cache across
namespaces that use different modules to implement a particular module
path or that enable the JIT differently. In particular, starting with
one that has a procedure binding and then using one (in a different
namespace) that has a non-procedure binding could lead to a crash.
Defend against this possibility by never treating imported variables
as constant in that sense. The JIT detects imported variables through
a new import map in the prefix.
This change may slow code. My guess is that it will have no
performance impact in practice, due to cross-module inlining,
although I can construct a microbenchmark that slows by 20%.
The optimizer can no longer reduce
(with-continuation-mark _id _v-expr _expr)
to just
_expr
when _v-expr and _expr are simple enough, because _id
might be bound to a continuation mark key with an
impersonator that checks the result of _v-expr.
The loss of an optimization can have a significant affect on
errortrace of microbenchmarks, such as
(for ([i (in-range 10000000)])
i)
A arity-reduced procedure-valued `prop:procedure' was not handled
correctly, for example.
A good candidate for random testing? I had the right kind of test in
place, but only for an arity of 1. It turns out that testing any other
arity would have exposed the problem, so now there are tests with
arity 0. If I had randomly generated procedures instead of manually
constructing `f0' through `f1:+' in "procs.rktl", then maybe I would
have more naturally generalized the arity testing, too. Then again,
I did already have relevant inputs, and it was the testing of inputs
that was too specific.
Closes PR 12870
For all currently supported platforms, the result was already
portable, despite the documentation's hedging.
Also fixed up the documentation in other ways, such as the fact
that `seconds->date' returns a `date*'.
Add extra intitial-message lines, use "..." on a field name
to indicate that it could reasonably be hidden by default,
and refine some existing messages.
Includes the addition of 'overflow and 'start-overflow-work
events, whcih are effectively specializations of 'sync and
'start-work to expose overflow handling.
Also, fix a bug related to a potential GC during mark-stack
restore from a lightweight continuation.
By itself, this change won't help anything, because tail-call
allocation is triggered for something that can't be called directly.
This change sets up part of an improvement for future-local recovery
from stack overflow, though.
(I had trouble constructing a test that would trigger the new code.
Fortunately, the existing tests trigger it.)
When a "synchronized" operation is handled for a future thread
during a `touch' on the future, then still report the handling
as "synchronized" insteda of "blocked".
Also, fix FFI procedures to preserve names: change `ptr-ref' with
`_fpointer' on an `ffi-obj' value to return the `ffi-obj'
value, so that the name in the `ffi-obj' value can be used
by `_cprocedure'.
Closes PR 12645
The new predicates are `progress-evt?' `thread-cell-values?',
`prefab-key?', `semaphore-peek-evt?', and `channel-put-evt?'.
These were used internally, and now they appear in contract
error messages.
When supplying an accessor to redirect, either the corresponding field
must be accessible through the current inspector, or a mutator for
the same field must be redirected, too.
Stevie realized that we need this constraint; otherwise, impersonators
can implement mutator-like behavior even when the mutator is otherwise
secret.
Add `raise-argument-error', `raise-result-error', `raise-arguments-error',
and `raise-range-error'.
The old convention was designed for reporting on a single (sometimes very
long line). The new convention is
<name>: <short message>
<field>: <detail>
...
If <detail> is long or itself spans multiple lines, then it may
also use the form
<field>:
<detail>
where each line of <detail> is indented by 3 spaces.
Backtrace information is shown as a multi-line "context" field.
For example, if definitions have two unmarked `x's that originate
from different modules, make them correspond to different bindings.
This improvement will be used by `scribble/srcdoc', which will
rely on module context to connect `for-doc' requires to documentation
code that appears in the same module --- which is needed, for example,
if a macro expands to documentation code and the macro is used in
a different module.
These primitives atomically update a box to a new value, as long
as the current value is the same as a provided value. They also
are future-safe.
When futures are enabled, they use low-level hardware instructions
to perform the change atomically.
The expander no longer needs to generate certain phase-N
identifiers, since we now have a comparison operation that
uses different phases for each of two identifiers.
The preserved path is exposed by a new `module-path-index-submodule'
function, and `module-path-index-join' now accepts an optional
submodule path.
Also, fixed a problem with `collapse-module-path-index' when
a module path indx is built on a resolved module path that
is a submodule path.
In addition to the main repair, `collapse-module-path[-index]' is
correctly documented to allow '(quote <sym>) rel-to paths.
Finally, `collapse-module-path-index' changed to use a symbolic
resolved module path that appears as the base of a module path
index, rather than falling back to the given rel-to path. It's
possble that the old beavior was intentional, but it wasn't tested,
and it seems more likely to have been a bug.
Closes PR 12724
For example, `(module-declared? '(submod (planet dyoo/bf) reader) #t)'
shouldn't fail if there's no "main.rkt" to hold a `reader' submodule;
it should return #f.
Merge to 5.3, but updating cstartup.inc will require a manual merge.
AVL trees to tend to be shorter, which means a faster
search and insertion. The potential benefit of a red--black
tree's fewer rotations doesn't matter, I think, for a functional
variant, where you have to reconstruct a spine to the root,
anyway. The difference is small for typical tables, though it
can be as much as 50% for a large table with keys inserted in
order. And since the AVL code is also much simpler, why not?
The usual techniques: shortcut around generic scheme_apply() for
chaperone-triggered slow path, shortcut around scheme_apply() for
application of a native-code interposition function, and shortcut
`chaperone-of?' test by trying `eq?' first.
The immediate symptom was that `(provide (all-defined-out))'
didn't work in a `module+'-based submodule, but there were
also non-submodule ways to expose the problem.
Although th eoriginal idea was to distinguish "text" paths
from derived filesystem paths, practically everythign that accepts
a module path also accepts a path. Building the generalization into
`module-path?' makes it easier to support `submod' wrappers on paths,
and it seems to fix things rather than break them.
