I'm not sure why, but these tests seem to emit one of two different
errors depending on the machine it's run on (hence the failure in
DrDr). For the short term, I've set the regular expression to allow
either of them.
This allows us to type-check non-recursive sequences of
letrec-values clauses in the right order. In other words,
we will type-check the clauses in reverse topological
order (the reverse of the dependency order).
Clauses that are recursive go through the usual
type-checking process, injecting Undefined where necessary.
The types for racket/gui are substantially complete, but
there are still some missing classes and methods.
Some interesting future work would be to ensure type coverage
by comparing the class members vs. the types in the environment.
That could be run as a test to ensure it stays up to date.
Most types for the framework library are still missing.
This expands the `Name` type functionality to go
beyond struct names and allows arbitrary recursive
type aliases to use the environment for indirection.
In addition, such aliases can be mutually recursive.
Note that even the movement of operations like `unsafe-fl+` is
constrained, since the operation can allocate. For example, a
continuation captured in
(let ([a (unsafe-fl+ x y)])
(call-with-composable-continuation ....)
a)
should return an `eq?` result. The compiler must not only refrain from
moving the `unsafe-fl+` call, it must not mark `a` as a flonum
binding, because that would cause the JIT to delay allocation of `a`
until the return site.
Perserve and adjust timestamps in a way that helps make re-packing an
installed-from-built package produce an archive with the same checksum
as the original.
The description does not mention the function ever returning #f
and if you look at the implementation in the C code, it always
returns the result of `scheme_make_integer`.
Also add an example for the entry.
I'm running into stuck processes via `subprocess`, where the stuck
process is in malloc() for environment variables. I'm not really sure
of the problem, but moving that work before the fork() could
avoid problems related to pages or signal handlers.
