exports and drracket:tool^ be in sync
This doesn't quite do the whole job
because something seems to get names
confused when structs and signatures
team up. This is a small example that, I
believe, demonstrates the problem:
(require racket/unit)
(struct p:s ())
(define p:struct:s struct:p:s)
(define-signature s1^
((struct s ())))
(define-signature s2^
((open (prefix p: s1^))))
(define-values/invoke-unit
(unit (import s2^) (export))
(import s2^)
(export))
teachpacks that were last selected by the user
This change is related to PR 14089 because that PR
made me realize that a similar problem happens with
this pref file. There is a simple fix, tho: just keep
the preferences for 5.3.6 and earlier using a different
key than the preferences for versions released after 5.3.6
Avoids including the bit thet indicates whether the object
is GCable in the eq hash code (in a configuration where
bits are available in the GC header for hashing).
Closes PR 14059
Symbols in the PR were mapped to coliding hashes in
groups of 4 because the low 2 bits of the `eq?` hash
code were begin dropped to generate an `equal?` hash
code. Those two bits got lost due to a refectoring
a while back that moved the dropping of two useless
bits to a more centralized place, but the 2-bit shift
did not get removed from the `equal` hash code comparision.
The PR's example program will still generate groups of 2
when hashing around 10k symbols (which used to be groups of 8).
That's because there's a bit in the hash-code counter that
turns out to be forced to 1.
The problem mainly affected `register-custodian-shutdown`
from `ffi/unsafe/custodian`, which is used by `math/bigfloat`
and `ffi/unsafe/com`.
When a value is registered with a custodian, the value is held
weakly, but the shutdown procedure is intended to be held
strongly. At the C API level, the data associated with a shutdown
function pointer is intended to be held strongly.
A custodian itself, however, is retained weakly by other custodians
in its family, so that custodians can be GCed and their elements
transferred to a parent custodian. Since the custodian itself may
be held only weakly, the callback & data in a custodian was effectively
held weakly --- which, in turn, can break assumptions in code such
as `ffi/unsafe/custodian` that expects strong references to prevent
finalizers from running.
Fix the problem by registering a reference to callback data as
data in a custodian's finalizer, which makes the data strongly
retained no matter how the custodian is retained.
