If a Git package source does not include "#" followed by a ref, then
use the branch/commit designated by a server as the default branch or
commit (i.e., the one for the "HEAD" symref), instead of assuming the
branch "master".
This is technically a backward-incompatible change to the
interpretation of Git package sources, but explicit branch
specification continues to work the same. For the forseeable future,
to support recent versions, packages in a branch other than "master"
will still need to be specified using the branch name, such as
including "#main" at the end of the package source. Eventually,
relevant versions of Racket will support the new default.
Relevant to #3672
Also, change the default ref from "master" to 'head. This is
technically a backward-incompatible change, but so far it seems more
likely to make things work right than to break them.
In Racket BC, callbacks don't have to be atomic, and it's ok for the
callback to raise an exception (as long as the foreign library is ok
with a longjmp escape). Using `#:callback-exns? #t` on a foreign
callout in both CS and BC allows an atomic callback (invoked during
the foreign call) to raise an exception. Terms and conditions apply.
When a string is large enough, its conversion to bytes is internally
streamed, and `regexp-match/end` did not get the match-ending bytes
correctly.
Closes#3684
The predicate for a seald structure type can be faster than a
predicate for a non-sealed structure type, and Chez Scheme takes
advantage of that opportunity.
The BC JIT could be improved to take advanatge of sealed structure
types, but it isn't.
This commit also fixes CS checking of a supertype for certain shapes
of prefab struct-type declarations.
Saving and restoring the signal-mask state does not work right, since
rktio itself may block SIGCHLD in some cases, and it doesn't seem
useful/right to preserve the mask after fork.
The docs currently state that `flat-contract-predicate` is merely a holdover for backwards compatibility, and that flat contracts can be used directly as predicates now. This isn't correct: _some_ flat contracts can be used directly as predicates, but not all. Ordinary racket values that double as contracts such as numbers and symbols can't be used as predicates without using `flat-contract-predicate`. Additionally, this pull request directs users to `coerce-flat-contract` if they're seeking to build contract combinators that explicitly convert ordinary racket values into flat contracts.
Context: racket/scribble#293.
For each signal handler that is changed, save its state, and restore
the state in a child process after a `fork` and before an `execve`.
Also save and restore the signal mask.
This change requires cooperation from various subsystems, which often
takes the form of a callback registered with the subsystem to be
called before adjusts a signal handler.
Closes#3609
Forbidden set operations on weak sets produced slightly confusing error
messages:
> (define s (weak-set))
> (set-add s 42)
; set-add:
; expected: (not/c set-mutable?)
; given mutable set: (weak-set)
; argument position: 1st
> (set-mutable? s)
#f
Invoking an operation that required an immutable set gave a message
saying that a `(not/c set-mutable?)` was expected, but a `weak-set` is
not recognized by `set-mutable?`, which only recognizes mutable sets
with strongly-held keys. Changing `set-mutable?` to recognize weak sets
seems undesirable.
This patch changes the error message so that the above example produces
the following error:
> (define s (weak-set))
> (set-add s 42)
; set-add:
; expected: (not/c (or/c set-mutable? set-weak?))
; given mutable set: (weak-set)
; argument position: 1st
Instead of keeping a rectord type's ancestry in a vector ordered from
subtype to supertype, keep the vector the other way around, and
include a record type at the end of its own vector. This order makes a
more direct test possible when checking for a known record type,
especially one without a supertype, and it's generally easier to
reason about.
The revised compilation of record predicates trades some speed in one
case for smaller generated code and speed in other cases. The case
that becomes slower is when a predicate succeeds because the record is
an immediate instance of the record type. The cases that go faster are
when a predicate fails for a non-instance record or when a predicate
succeeds for a non-immediate instance. It's possible that an
immediate-instance shortcut is worthwhile on the grounds that it's a
common case for a predicate used as contract, but we opt for simpler
and less code for now, because the difference is small.
Also, add `record-instance?`, which in unsafe mode can skip the check
that its first argument is a record, and cptypes can substitute
`record-instance?` for `record?` in some cases. This change was worked
out independently and earlier by @yjqww6, especially the cptypes part.
Related to #3679
