When packages A and B have the same Git repository source, and
when at least one of them is linked as a repository clone, then
the package system doesn't require A and B to both be linked or
both be linked to the same clone... but that can lead to confusion
for users. The package manager now detects this situation and in
many situations can update non-clones to make then clone links
at the same repository.
When a package is installed via a catalog, and the source provided
by the catalog is a Git repostory, then allow `--clone` to use
that repository when just the package name is given.
Using `--clone <dir>` with a Git-based package source causes the
package installation to be linked to a clone of the repository
as a subdirectory of <dir>. The package can be developed locally
in the usual way with Git tools, but `raco pkg update` can itself
pull updates to the package/repository.
See the new chapter 6 in "Package Management in Racket" for
more information.
When an overriden method implements a subtype of the superclass
type, sometimes the typechecker gets confused what the type should
be in the resulting class type.
This check was not really necessary to begin with,
but I thought it might be a useful sanity check. In
retrospect, calling `subtype` here causes other headaches
(such as when registering type aliases) and is confusing
when multiple #:implements are provided.
Instead, the #:implements clauses are just linearized
and the last type for any given method/field is taken.
This may also prevent a heisenbug that occurs in the
GUI framework types. I still don't know the root cause of
that non-determinism though.
Closes PR 14669
also, Rackety for 102 columns and drop the nat? and
extended-nat? exports, using instead the standard
names for those concepts: exact-nonnegative-integer?
and (or/c exact-nonnegative-integer? +inf.0)
Macros often expand into forms where the subforms have
the same syntax location as the entire form, which means
a naive approach gives confusing type tooltips on macro
expressions.
Instead, only keep the latest (outermost) type tooltip
for a given expression.
We could instead compute whether a given piece of syntax
is a subform of another at a given location or not, but
that check is expensive and we don't want to do that on
every update of the type table.
