A procedures that is a value for a structure-type property was not
always inspected correctly. For example, if such a procedure was the
only one to mutate a module variable, then the variable might not be
detected as mutable.
Since CS doesn't use secondary hash code internally, the
`equal-secondary-hash-code` function wasn't really implemented.
Implement it reasonably for applications that might use it to
implement other data structures.
Testing exposed other problems related to error reporting for a broken
hash-function result and for using values within immutable hash
tables.
Closes#3536
Fixes an issue where the distribution assembler expects these to be
`path?`s.
I originally considered making this change in the ctool command in
`cext-lib` instead, but then I noticed the documented contract for
`assemble-distribution` is `(or/c #f path-string?)`.
AArch64 Mac OS will not run an unsigned executable. But it will happily run an
executable with an "ad hoc" signature, which is little more than a sequence of
SHA-256 hashes of the file content.
Meanwhile, new tests highlight how the `pretty-print` family of
functions is inconsistent with the non `pretty-` variants (worth
changing, considering backward compatbility?).
Currently, the pattern matcher always call `vector->list`
on the input vector if a ddk is detected.
However, when there is exactly one ddk and users wish not to
bind an identifier to the ddk, the whole conversion is not needed.
Instead, we can selectively `vector-ref` the prefix and the suffix
of the vector and match them directly against patterns.
Also strengthen an existing test.
They were being converted to fixnum operations in unsafe mode, but
the intent was to use fixnum operations only when the argument are
known to be fixnums.
The latest Mac OS tools automatically sign code when linking, and
"collect-path.rkt" break that signature by changing the executable.
Avoid that problem by removing the signature, first. (Leave it to
distribution tools to install a new signature.)
Code segments are executable and potentially non-writeable in a thread
--- except when specifically enabled, at which point code segments are
made non-executable for that thread. Non-code segments are always made
non-executable.
