Modules are not supposed to move to different packages, anymore, so
I'm breaking a rule. The problem is that having `rackunit/docs-complete`
in "scribble-lib" made "scribble-lib" depend on "racket-index", and
that's an undesirable dependency. (Installing Scribble shouldn't
force you to have Racket documentation.) I should have noticed
the problem when I moved `setup/xref` to "racket-index", but I missed
it.
As far as I can tell, there's only one package on pkgs.racket-lang.org
that isn't in the main repository and uses `rackunit/docs-index`. The
package doesn't correctly declare its dependencies, anyway.
Binary package installation failed in the case of collection
splicing, because module-name resolution via `collection-file-path`
did not check for compiled files along hte search path of
registered collection directories.
A "file://" prefix on a package source needs to be consistently
removed. The new `package-source->path` function does that, so it
should be used to convert a package source to a filesystem path.
Use a recursive call to try again, instead of trying to reset local
state. The reset-local-state variant is definitely broken in
some caes, though I could not provoke the JIT buffer overflow
that I was hoping to fix with this change.
The optimizer's inference that could incorrectly that that a
conditional produced a flonum (when it actually produced a fixnum or a
fixnum in one branch and flonum in the other).
As in "Fixing Letrec". This improvement corrects a performance
regression with the revised expansion of R5RS `letrec`, which
wraps right-hand sides with `values`.
Besides detecting effect-free primitives, we have to fix the
treatment of the right-hand side for a multi-binding `letrec-values`
clause. For now, we conflate all of the bindings in a single
clause.
Fix some comparisions that are written as pointer comparisons
when they're actually integer comparisons. Also, remove an
unnecessarily slow variant of pointer compairson for x86_64.
On x86_64, the JIT compiler initially generates code with 32-bit
jumps, but it switches to 64-bit jumps when so much code is allocated
that it gets spaced out enough. That transition could happen during a
recursive call to the JIT compiler or while one place is in the JIT
and other installs a shared code pointer, in which case a bad jump
could be generated. This problem is unlikely to happen, but it looks
possible.
