Nested splicing forms would lead to an "ambigious binding" error when the nested forms bind the same name, such as in (splicing-let ([a 1]) (splicing-let ([a 2]) (define x a))) The problem is that splicing is implemented by adding a scope to everything in the form's body, but removing it back off the identifiers of a definition (so the `x` above ends up with no new scopes). Meanwhile, a splicing form expands to a set of definitions, where the locally bound identifier keeps the extra scope (unlike definitions from the body). A local identifier for a nested splicing form would then keep the inner scope but lose the outer scope, while a local identifier from the outer splicing form would keep the outer scope but no have the inner one --- leading to ambiguity. The solution in this commit is to annotate a local identifier for a splicing form with a property that says "intended to be local", so the nested definition will keep the scope for the outer splicing form as well as the inner one. It's not clear that this is the right approach, but it's the best idea I have for now.
A `#:module-wrapper` option is useful for adding a scope to an entire `module` form.
Although `eval-syntax` is not supposed to add the current namespace's "outer edge" scope, it must add the "inner edge" scope to be consistent with adding the inner edge to every intermediate expansion (as in other definition contexts). In addition, `eval`, `eval-syntax`, `expand`, and `expand-syntax` did not cooperate properly with `local-expand` on the inner edge.
1st is a small grammatical mistake 2nd is in a section about ->* yet mistakenly -> is referred to 3rd is about recontract-out yet contract-out is mentioned instead 4th clarifies return value for value-contract 5th replaces free-identifier? with free-identifier=?
Recent changes introduced an indirect dependency in the core of `raco setup` --- possibly the recent addition to `racket/place`.
Genereating a use-site scope, instead of a macro-introduction scope, prevents the scope's presense from triggering a #f result from `syntax-original?`.
This change mostly reverts 1465ff2, which turned out to be a hassle because it created more cyclic structure. A simpler strategy is to allow a phase-specific scope to be detached (perhaps temporarily, due to on-demand loading of bytecode) from its group; when that's possible, the scope is not reachable from a place where it can be moved to other syntax objects, so it's ok to be detached. Debugging output needs to handle that gracefully, though. Also, in case of broken bytecode, fix up a detached scope if it does end up in an unexpected place.
Also, fix the interaction of submodules plus `--collects-dest`, but there's room for improvement there in pruning unused submodules.