| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This test currently fails because when we execute an
unsuffixed file like test/019/a, which exists,
another file is executed instead, like test/019/a.txr.
* tests/019/data/a,
* tests/019/data/a.tl,
* tests/019/data/a.tlo,
* tests/019/data/a.txr
* tests/019/data/b.tl
* tests/019/data/b.tlo
* tests/019/data/b.txr
* tests/019/data/c.tl
* tests/019/data/c.txr
* tests/019/load-search.tl: New files.
|
|
|
This test currently fails. This problem was reported
by Paul Patience, with a repro test case.
The issue is that when compile-file is processing a
(defpackage x ...) form, and the package x already exists, it
fails to recognize the form as a package-manipulating form,
and therefore fails to introduce a "fence" in the output
so that subsequent material is placed into a new top-level
object.
The compiled image fo the (defun foo:fun ()) form in
program.tl causes an error: the foo package does not
exist. This is because the symbol foo:fun is being read
as part of the same object which holds the compiled image of
the defpackage form which defines the package.
It's essentially the same problem as this
(let ()
(defpackage :foo)
foo:bar)
The (defpackage ...) cannot execute until the entire form is
read, but that form contains foo:bar which requires the foo
package to exist.
* tests/019/compile-package.tl: New file.
* tests/019/data/program.tl: Likewise.
|
