Part of the clarification is duplicating information about numbers
and character in the documentation of `eqv?`. Since those two type
are the only special cases of `eqv?`, the duplication seems helpful
and managable.
be equal?-based contracts instead of = based contracts.
Before this change, the contract (or/c 1 2 +nan.0) was the same
contract as (or/c 1 2), because +nan.0 was the same contract as
the predicate (lambda (x) (= x +nan.0)), which is the same as
(lambda (x) #f). Now, +nan.0 and +nan.f are the only numbers
that are treated as equal?-based contracts, but this means that
(or/c 1 2 +nan.0) actually accepts +nan.0.
Rending a document can deserialize values, which can load modules
that would otherwise not be loaded by Scribble, so render each
document with a fresh namespace that is discarded after rendering.
A `this%` expression used in a finalization callback implicitly
referred to `this`, since it's a dynamic reference to the object's
class. As a result, the finalizer for `this` refers to `this`, so
`this` never becomes collectable. The problem is fixed by
lifting the `this%` out of the `lambda`.
Less significantly, the finalizer thread in "prepared.rkt" captured
various parameters on creation, including the current namespace. If a
prepared statement is bound to a module-level variable, then the
finalizer thread refers through the namespace to the prepared
statement, so the prepared statement can never be finalized. Setting
the current namespace to a fresh empty one while creating the thread
avoids that specific problem. (Other parameters could cause similar
problems, but solving the namespace one works well enough for now.)
Optimization can cause a `lambda` that was going to refer to a
top-level variable or syntax object to not refer to it after all.
Ideally, the prefix should be dropped from the closure, but
the change here is more conservative: it fixes the `lambda`s
annotation that's used by the GC to indicate that nothing will
be used from the prefix.
For GC purposes, if a "prefix" (a closure frame that caprues
top-level or module-level bindings) may refer to syntax objects
that are not used by any reachable closure, in which case the
syntax object can be dropped. This pruning of syntax objects
uses the infrastructure already in place to prune variables.
Syntax objects were not included in the original pruning
implementation, because they are unlikely to create
finalization cycles in the way that global-variable
references can. A syntax object can retain a namespace's
table of module imports, however, which can be substantial
and worth releasing of a closure is only held, say, for
a low-level finalization action.
Although names were cleared correctly, the trie used for
the mapping was not pruned correctly, so lots of empty
branches could accumulate (especially in 64-bit mode).
Even when `(variable-reference-constant? (#%variable-reference ....))`
cannot be optimized to a boolean, the expression should not retain a
reference to the enclosing namespace. That space guarantee is
important for the compilation of calls to keyword-accepting functions.
The handling of `for-template` imports by `namespace-attach-module`
didn't match the docs. The actual handling was to refrain from
attaching instances of a phase-0 module if the instance was reachable
only through a `for-template`. The rationale had to do with such
modules instances being created only through instantiation of
phase-1 modules, and phase-1 module instances aren't attached;
it doesn't work well that way, though, when different modules
are attached with intervening `namespace-require`s on the target
namespace.
The change includes a documentation correction. Previously and still,
only modules at the same phase as the attached module (as opposed to
the same phase or less) are instantiated in the target namespace.
Closes PR 14938
Document and and exploit that any fragment in the Git or GitHub URL
for a package source must name a branch or tag (as opposed to a
commit) to work with clone linking.
