The new function allows declaration of a module dependency, as
opposed to a mere file dependency. Misuse of this function opens
the door to cyclic compilation dependencies, so we have to check
for that in `compiler/cm'.
I started from tabs that are not on the beginning of lines, and in
several places I did further cleanings.
If you're worried about knowing who wrote some code, for example, if you
get to this commit in "git blame", then note that you can use the "-w"
flag in many git commands to ignore whitespaces. For example, to see
per-line authors, use "git blame -w <file>". Another example: to see
the (*much* smaller) non-whitespace changes in this (or any other)
commit, use "git log -p -w -1 <sha1>".
Shape information allows the linker to check the importing
module's compile-time expectation against the run-time
value of its imports. The JIT, in turn, can rely on that
checking to better inline structure-type predicates, etc.,
and to more directy call JIT-generated code across
module boundaries.
In addition to checking the "shape" of an import, the import's
JITted vs. non-JITted state must be consistent. To prevent shifts
in JIT state, the `eval-jit-enabled' parameter is now restricted
in its effect to top-level bindings.
Bytecode changes in two small ways to help the validator:
* a cross-module variable reference preserves the compiler's
annotation on whether the reference is constant, fixed, or other
* lifted procedures now appear in the module body just before the
definitions that use them, instead of at the beginning of the
module body
An attempt to detect a submodule could trigger the original module
name resolver when the would-be enclosing module would be handled
by the embedding-specific resolver. When a submodule is not found
but its would-be enclosing module is embedded, then assume that
the default resolver wouldn't find the submodule, eithe --- and
therefore avoid a potential "collection not found" error.
The new parameter (and supporting environment variables and
command-line flags) can bytecode lookup to a tree other than
where a source file resides, so that sources and generated
compiled files can be kept separate. It also supports storing
bytecode files in a version-specific location (either with
the source or elsewhere).
When a module is loaded from bytecode and then the value of
`use-compiled-file-paths' changes, an attempt to load a submodule
would fail, because source isn't used if the main module is
already declared, and the bytecode code is not used according to
`use-compiled-file-paths'. Make the bytecode path stick when it
is used once, so that submodule loads succeed, and make it work
even with `namespace-module-attach'.
The module-attach part of this protocol requires a change to the
API of a module name resolver: the notification mode gets two
arguments, instead of one, where the second argument is an
environment.
The libraries moved were:
- mzlib/control => racket/control
- mzlib/date => racket/date
- mzlib/deflate => file/gzip
- mzlib/inflate => file/gunzip
- mzlib/port => racket/port
- mzlib/process => racket/system
- mzlib/runtime-path => racket/runtime-path
- mzlib/shared => racket/shared
- mzlib/unit => racket/unit
- mzlib/unit-exptime => racket/unit-exptime
- mzlib/zip => file/zip
The old modules in mzlib are now pointers to the
new modules. These are all modules that were already
redirected in the documentation.
This convention makes it easier to deal with a set
of ".rkt" files that implement tests, while a `test'
module implements a `main'-like split for some of the
files.
This addition triggered several other changes:
* -k for a Mac OS X embedding is now relative to the __PLTSCHEME
segment (which means that executables won't break if you strip
them, for example)
* the command-line no longer has a limited size for Mac OS X
launchers and embedding executables
* Mac OS X GUI and Windows launchers record the creation-time
collection path, unless they are created as "relative" launchers
In particular, allow a pair of a relative-to directory and a base
directory. Paths that syntactically extend the base directory are
recorded as relative to the relative-to directory (which must
syntactically extend the base directory).
The compilation manager now sets the parameter to a pair with
the base directory as the main collection directory, if the source
file's path extends that directory's path.
This generalization solves problems created by cross-module inlining,
where the source location of a procedure in bytecode can now be in a
different file than the enclosing module's file.
Also add a test that checks whether the build directory shows up
in any ".zo", ".dep", or documentation ".html" files.
Closes PR 12549
