* generics: optional scope arg for private macros
To make them more friendly to macros that expand to generics
* add tests for generic-method-table macro
The process of creating an installer involves building "racket-index"
in user scope, but the license and acks files are normally only in
installation scope. An explicit targeting of the installation-scope
output needs to be disabled when the documentats are rendered to
user scope.
Closes#1635
and/c, and between/c (which implies <=/c and >=/c) so that they turn
themselves into integer-in when appropriate
for example, (contract-stronger? (integer-in 0 4) (and/c natural? (<=/c 4)))
returns #t
- positive-integer?
- negative-integer?
- nonpositive-integer?
- nonnegative-integer?
These are like their exact-* counterparts provided by racket/base,
but they work for inexact numbers, and not just exact ones.
Fix problem with once-use tracking and delayed variable-use marking
that is performed for local function bodies. A delayed variable-use
registration might happen after a once-used variable is replaced by
its use.
This scenario is difficult to provoke, because the optimizer has to
first decide not to move a once-use function, and in a latter pass
decide to move it after all. There's not enough information to
retract the tentative use plus its transitive implications.
The solution is to avoid the generic once-use layer for `lambda` forms
whose uses are delayed (and that likely has a good effect on inlining
anyway). The other half of the solution is to avoid transitive use
marking on a once-used variable whose expression has been moved (and
there are no transitive things to skip, because that expression isn't
a `lambda` form).
It appears that Mac OS wants `RTLD_LOCAL` in the dlopen() call,
otherwise dlsym() searches through all previously open shared objects
– even though dlopen() is given a specific library handle.
The previous for/fold/derived examples in the docs
incorrectly expanded, placing the entire body of the
user defined for loop into a let expression inside of
for/fold/derived. This meant that break clauses (i.e. #:break
or #:final) that appeared in the body of the user-defined
for loop were not visible to the underlying for/fold/derived
macro after expansion and therefore usages of #:break or #:final
incorrectly resulted in syntax errors (since with the incorrect
expansion, they were seemingly misplaced keywords inside of a let).
With this PR the for/fold/derived examples in the docs now
expand correctly into a form that mirrors the actual
expected syntax of for loops:
(user-defined-for (for-clause ...) body-or-break ... body)
==(now expands more or less into)==>
(for/fold/derived (for-clause ...) body-or-break ... body)
Or in other words, the body of the user defined for loop now correctly
expands directly into the body of for/fold/derived.
