Previously, fibers had a hard-coded limit to how big their stack size is. This limit exists in two forms: the number of distinct call frames (basically the maximum call depth), and the number of unique stack slots. This fixes the first half of this by dynamically allocating the call frame array and growing it as needed. This makes new fibers smallers since they can start with a very small array. Checking and growing as needed doesn't noticeably regress the perf on the other benchmarks, and it makes a new fiber benchmark about 45% faster. The stack array is still hardcoded, but that will be in another commit.
This contains the automated validation suite for the VM and built-in libraries.
-
benchmark/- Performance tests. These aren't strictly pass/fail, but let us compare performance both against other languages and against previous builds of Wren itself. -
core/- Tests for the built in core library, mainly methods on the core classes. If a bug is inwren_core.corwren_value.c, it will most likely break one of these tests. -
io/- Tests for the built in IO library. In other words, methods on theIOclass. If a bug is inwren_io.c, it should break one of these tests. -
language/- Tests of the language itself, its grammar and runtime semantics. If a bug is inwren_compiler.corwren_vm.c, it will most likely break one of these tests. This includes tests for the syntax for the literal forms of the core classes. -
limit/- Tests for various hardcoded limits. The language doesn't officially specify these limits, but the Wren implementation has them. These tests ensure that limit behavior is well-defined and tested.