Racket wasn't reparsing correctly; the strategy worked ok
for links created by `mklink`, but not with other tools that
leave the "printed name" field blank.
A consequence of various fixes is that reparse points like
"My Documents" (in a typical configuration) correctly resolve
to actual paths like "Documents".
Finally, `directory-exists?` didn't handle root directories like
"C:/" correctly. The query would actually report properties of
the OS-level current working directory, and when junctions are
involved, the current directory can be a link instead of a directory.
Relevant to PR 14950 and PR 14912
Unlike `collapse-module-path`, it makes sense for
`collapse-module-path-index` to convert a relative module path index
to a plain module path. In other words, `collapse-module-path-index`
can convert a module path index to a module path.
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).
