The beginning of the "Inside" documentation was still geared toward
writing extensions or embedding Racket, which almost no one does any
more. Shuffle and change the beginning to orient it around the
foreign-function interface, instead.
This also applies to `(mlist x ...)`, even though
that involves two traversals when only one is
required by the old method. Timing suggests that
the new code is nonetheless faster.
This is the third try to fix the bug exposed by "fuzz.rkt". Previous
repairs addressed a symptom at the point of printing bad symbols,
instead of the cause at a failure to validate a symbol's encoding
when reading bytecode. This one fixes reading.
Commit 6a5a3037b4 was not quite right, because it used sightly the
wrong variant among a dozen decoding functions. The test suite caught
the problem, but I forgot to run it before pushing.
Also, repair the "Inside" documentation on the function that was
incorrectly used, and document the new variant.
Allow an effect-free `if` to not increment the effect-tracking
virtual clock (but increment the clock during branches, to avoid
moving computation into a branch).
Spend empty-`let`-elimination fuel more precisely, so that more
empty `let`s can be removed while still avoiding quadratic
compile times.
Tells the user which missing keywords were mandatory and
which were optional (which is useful if, e.g., the expected type
says mandatory but the function had it optional).
Convert
(let-values ([(<id> ...) (if <id-t>
(values <e1> ...)
(values <e2> ...))])
....)
to
(let ([<id> (if <id-t> <e1> <e2>)]
...)
....)
which duplicates the `(if <id-t> ....)` test, but that's likely to
be worthwhile to avoid multiple-values shuffling and enable more
constant and copy propagation.
A related improvement is to more eagerly discard `let` wrappers
with unused bindings during optimization, which could enable
further optimization, and allow moving conditionals relative
to other expressions to avoid intermediate binding.
Eagerly discarding `let` wrappers exposed a bug in the optimizer's
shifting of variable locations by exercising the relavant shifting
operation in shift_closure_compilation().
Closes PR 14588
While the commit comment in 3150b31eb7 still seems right, the changed
overlooked the fact that the arguments to a split `values` might get
reordered (due to the way binding positions are calculated). Fix the
optimizer to make sure that reordering is allowed.
The change touches a lot of code, because we want to use
"omittable" to implement "movable", and it's not ok to
reorder access of mutable variables (in case some other thread is
mutating them). We have to fix all the calls to "omittable"
to support the slight generalization.
in certain situations
Specifically, don't compute the identifiers-hash before opening the
menu but, when it does need to be computed, avoid consider the same
arrows over and over. This makes an especially big difference when a
region of text is selected that contains lots of arrow heads that all
point to a place that has lots of arrows.
Specifically, the time to compute the identifers hash for the example in
the PR is now about 200x faster (altho this still takes 200 msec, which
is why it isn't computed at all in that sequence of steps any more).
closes PR 14586
