- Fix some doc comments.
- Inline comparing two ObjStrings, since it's only used in one place.
Also, this avoids a redundant identity check.
- Move the forward declarations of the object types out of
wren_common.h. Instead, I just added the one needed forward
declaration of ObjString in wren_utils.h. It's a little inelegant,
but it feels weird to me to expose all of the object types in
wren_common.h when they logically belong to wren_value.h and most of
the types aren't problematic.
- Fix a bug where field symbol tables weren't being marked. If a GC
happened while compiling a class, field strings got freed.
A statement like:
for (i in 1..2)
When run in the REPL declares a local variable ("i"), but not inside
a function or method body. This hit a corner case in the compiler
where it didn't have the correct slot indexes set up.
That corner case is because sometimes when you compile a chunk, local
slot zero is pre-allocated -- either to refer to "this" or to hold the
closure for a function so that it doesn't get GCed while running. But
if you're compiling top-level code, that slot isn't allocated. But top
level code for the REPL *should* be, because that gets invoked like a
function.
To simplify things, *every* compiled chunk now pre-allocates slot zero.
That way, there are fewer cases to keep in mind.
Also fixed an issue where a GC during an import could collected the
imported module body's closure.
Fix#456.
This is a breaking change because existing imports in user Wren code
that assume the path is relative to the entrypoint file will now likely
fail.
Also, stack trace output and host API calls that take a module string
now need the resolved module string, not the short name that appears in
the import.
This is just for the VM's own internal use, for resolving relative
imports.
Also added a tiny unit test framework for writing tests of low-level
C functionality that isn't exposed directly by the language or VM.
This is an interim step towards supporting relative imports. Previously,
the IMPORT_VARIABLE instruction had a constant string operand for the
import string of the module to import the variable from. However, with
relative imports, the import string needs to be resolved by the host
all into a canonical import string. At that point, the original import
string in the source is no longer useful.
This changes that to have IMPORT_VARIABLE access the imported ObjModule
directly. It works in two pieces:
1. When a module is compiled, it ends with an END_MODULE instruction.
That instruction stores the current ObjModule in vm->lastModule.
2. The IMPORT_VARIABLE instruction uses vm->lastModule as the module to
load the variable from. Since no interesting code can execute between
when a module body completes and the subsequent IMPORT_VARIABLE
statements, we know vm->lastModule will be the one we imported.
This is simpler and marginally faster. We don't need the overhead of
fibers since you can't have long or recursive import chains anyway.
More importantly, this makes the behavior more well-defined when you do
things like yield from an imported module. (Not that you should do that,
but if you do, it shouldn't do weird things.)
Instead of dynamically downloading these as needed during a build, this
checks in those two dependencies directly into the Wren repo. That's a
little lame because users of Wren who aren't building the CLI don't
actually need them, but they aren't too big, so it's not a huge deal.
It makes builds (particularly on Travis) more reliable, because they
don't have to pull down additional content over the network.
