Add Travis CI configuration to build and test Wren on both Linux and macOS, for both 32-bit and 64-bit architectures, with and without WREN_NAN_TAGGING defined. Introduce `ci_32` and `ci_64` make targets that build debug/release and C/C++ variants, then run the test suite against each binary using a suffix parameter. Update `util/test.py` with argparse to accept `--suffix` and `suite` arguments, increase test timeout from 2 to 5 seconds, and fix handle leak in `test/api/slots.c` by moving `wrenReleaseHandle` after the conditional block. Replace `fpclassify`/`signbit` checks for infinity/nan in `wrenNumToString` to avoid GCC overflow warnings on 32-bit, double-cast `double` to `uint32_t` in `num_bitwiseNot` to prevent undefined behavior, and relax floating-point comparisons in `test/core/number/sin.wren` and `cos.wren` to use absolute tolerance. Comment out hex literals larger than `0x1000000` in `example/syntax.wren` since they exceed 32-bit range, and bump libuv from v1.8.0 to v1.10.0 for 32-bit build fixes.
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. -
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.