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
This checks that the given lambda has the right keywords
wrt to the expected type. Doing this should avoid the bad
arity errors that result from the kw protocol encoding.
Closes PR 13898
The optimizer was willing to convert `(pair? (cons w (random)))` to
`(begin (random) #t)`, but not `(car (cons w (random)))` to
`(begin (random) w)` because the `(car (cons ....))` transformation
required simple ignored arguments. Put the treatment of ignored,
non-omittable arguments of a dropped operation in one place. Also,
recognize expressions within `begin` whose results will be ignored.
Windows parses relative-path links with yet another set of rules ---
slightly different from the many other existing rules for parsing
paths. Unfortunately, a few OS calls don't provide an option for
having the OS follow links, so we have to re-implement (our best guess
at) the OS's parsing of links.
This changes Filters to have a Path as a subcomponent instead of having
the list of Path-Elems and name-ref/c separately. This is part of the
rework to have better object support.
