Using a frame pointer for the ABI of internal helper functions
should make the stack friendlier to tools like `perf`. There
may be a small performance cost, though.
giving plain s-exps like you would for `require` is unlikely to work as expected.
Need use something that evaluates to the appropriate s-exp you want.
Added more examples of different `dynamic-require` uses.
Alexis's repair, and as she notes, forcing a `post-expansion` context
value in the core `#%module-begin` expander may allow a simplification
in "definition-context.rkt". But it's not immediately obvious, so save
that potential improvement for later.
Relevant to #2118
When `local-expand` receives one or more internal definition contexts,
it would forget about any current post-expansion scopes. That's
particularly a problem in a 'module-begin expansion context, where the
post-expansion scope ensures that any bindings are suitably
phase-specific.
Closes#2115
This is similar to the recent change of functions with optional
values. Using unsafe-undefined instead of a gensym makes it easier
to avoid the check of the missing argument.
When the separator is a string, these function construct a regexp
that is cached to make repeated calls faster. But when the string
is mutated it is necessary to recalculate the regexp.
Commit 32b256886e adds shifts in one place where it shoouldn't;
the "determinsitic-zo" test exposed the problem.
Also, avoid adding shifts that will have no effect, which avoids
accumulating useless shifts in some top-level contexts.
Various parts of the expander, including `local-expand`, always
flipped the use-site scope when flipping an introduction scope. Onlt
`syntax-local-introduce` should flip both of them, though.
Closes#2112
When expanding in a namespace for a module unmarshaled from ".zo"
form, a scope corresponding to the module's "inside edge" is added to
every expansion. Before this repair, the scope was detached from
module path index shifts that might apply to the bindings (including
references to bulk bindings). Repair the problem by adding suitable
shifts when adding the scope.
Thanks to William Hatch for the bug report.
As suggested by Sam: Using `racket/repl` to start a read-eval-print
loop can mean that less code is loaded if a startup language other
than `racket/base` is selected.
Closes#2064
- add comment saying `check-one-object/equivalent` only compares common
members
- put the similar parts of `check-one-object` and
`check-one-object/equivalent` in a helper function
- in `object/c-equivalent?`, check that names match before comparing the
common contracts (because the names should be fast to check-if-incorrect)
Although the documentation claimed that `read/recursive` produces
a plaeholder, that seems to be a leftover from a much older
reader (before `make-reader-graph`). Fix the new `read/recursive`
to be like the old one, and update the documentation.
Thanks to Alex Knauth for tracking down the unnecessary change
in reader behavior.
Related to #2099
Compared to v6.12, `map` & co. already provide better checking in
reporting an error when a keyword-requiring function is provided
with empty lists, but repair the error message to talk about
required keywords instead of just by-position arity.
Thanks to Philip McGrath for reporting the problem.
Related to #2099
If `local-expand` with a 'module-begin context introduces a macro
definition, but the definition is dropped while a non-macro definition
is later introduced, then make sure references go to the non-macro
definition.
This change also addresses a related scenario, where a
`local-expand`-discovered macro definition is not dropped, but it is
given an extra scope --- which amounts to the same thing from the
expander's perspective.
When a module body is expanded with `local-expand`, then submodules
can remain declared even if the submodule is discarded in the final
expansion. Since that's the way it has always been, leave it that way.
But also guard against a way of generating an import cycle via those
leftover declarations.
The `identifier-prune-lexical-context` operation doesn't really
work out with scope sets, and it was effectively disabled when
we switched the old expander to scope sets.
